RE: Re: ld for VMS?

RE: Re: ld for VMS?

[becker.ismaning]

   Hmm, third(?) attempt to get this through.

Usually,  ACLEDTSHR is the first member in imagelib.olb, the shareable image libary. VMS ships this library "expanded". But you can "reduce" such libraries with the /data qualifier. For VMS libraries "compressed" means to remove unused blocks from deleted modules.

> -----Ursprüngliche Nachricht-----
> Von: Tristan Gingold 
> Gesendet: Mo. 26.04.10 (13:04)
> An: Douglas B Rupp 
> Kopie: Jay K , binutils
> 
> Betreff: Re: ld for VMS?
> 
> 
> On Apr 26, 2010, at 1:01 PM, Douglas B Rupp wrote:
> 
> > Tristan Gingold wrote:
> >> On Apr 25, 2010, at 8:11 PM, Jay K wrote:
> >>> Tristan,
> >>>  I'm seeing the following:
> >>>  Any alpha-dec-vms-ld invocation with reasonable inputs fails an
> assertion:
> >>>   alpha-dec-vms-ld: BFD (GNU Binutils) 2.20.51.20100425 assertion
> fail /src/binutils/src/bfd/vms-lib.c:351
> >>>          BFD_ASSERT (sbm_sz>= sizeof (struct vms_dcxsbm) + l + 3
> * sbm_len);
> >>> in _bfd_vms_lib_archive_p. I'm not sure it is complaining about
> gas output or the libraries from VMS.
> >> This is an error due to a compressed library from VMS.  Maybe
> starlet ?
> >>> (gdb) p *abfd  $1 = {
> >>>  id = 6,   filename = 0x80ed54 "ACLEDTSHR", 
> >> And more precisely the member ACLEDTSHR.
> > 
> > It could be a shareable image library, not an object library. It
> will contain only a symbol table and a pointer to the .exe. ACLEDTSHR
> sounds like a shareable image to me.
> 
> Maybe.  But IIRC, shareable image were not compressed.
> 
> 
> 
> -----Ursprüngliche Nachricht Ende-----
        

Re: ld for VMS?

[Tristan Gingold]

On Apr 26, 2010, at 2:05 PM, becker.ismaning@freenet.de wrote:

>   Hmm, third(?) attempt to get this through.

Got it!

> Usually,  ACLEDTSHR is the first member in imagelib.olb, the shareable image libary. VMS ships this library "expanded". But you can "reduce" such libraries with the /data qualifier. For VMS libraries "compressed" means to remove unused blocks from deleted modules.

Ah, ah.  So I can try to reproduce the issue by using /data.  I suppose DCX was also involved, don't I ?

Tristan.

Re: ld for VMS?

[h.becker]

Tristan Gingold wrote:
> On Apr 26, 2010, at 2:05 PM, becker.ismaning@freenet.de wrote:
> 
>>   Hmm, third(?) attempt to get this through.
> 
> Got it!
> 
>> Usually,  ACLEDTSHR is the first member in imagelib.olb, the shareable image libary. VMS ships this library "expanded". But you can "reduce" such libraries with the /data qualifier. For VMS libraries "compressed" means to remove unused blocks from deleted modules.
> 
> Ah, ah.  So I can try to reproduce the issue by using /data.  I suppose DCX was also involved, don't I ?
> 
> Tristan.

Yes, "reduce" and "expand" is implemented with DCX.

RE: ld for VMS?

[Jay K]

Thanks. Very helpful.
Maybe the assert before failing should print "try library /data=expand foo.olb" or such?
Oddly, running that command over all files seems like a bad idea:
  I got something "unable to read symbols from starlet.olb". I lost the message.
  I replaced startlet.olb with a pristine copy and now just:

 /usr/local/lib/gcc/alpha-dec-vms/4_5_0/pcrt0.o:($DATA$+0x90): undefined reference to `lib$establish'

Looks like maybe I only have the older vaxc$establish in my libraries.
 I am only on 7.x not the current 8.x. The admin is interested in upgrading when he has time.
Maybe I should edit pcrt0.c. I'll look.

Thanks,
 - Jay


----------------------------------------
> Date: Mon, 26 Apr 2010 18:39:20 +0200
> From: becker.ismaning@freenet.de
> To: gingold@adacore.com
> CC: rupp@gnat.com; jay.krell@cornell.edu; binutils@sourceware.org
> Subject: Re: ld for VMS?
>
> Tristan Gingold wrote:
>> On Apr 26, 2010, at 2:05 PM, becker.ismaning@freenet.de wrote:
>>
>>> Hmm, third(?) attempt to get this through.
>>
>> Got it!
>>
>>> Usually, ACLEDTSHR is the first member in imagelib.olb, the shareable image libary. VMS ships this library "expanded". But you can "reduce" such libraries with the /data qualifier. For VMS libraries "compressed" means to remove unused blocks from deleted modules.
>>
>> Ah, ah. So I can try to reproduce the issue by using /data. I suppose DCX was also involved, don't I ?
>>
>> Tristan.
>
> Yes, "reduce" and "expand" is implemented with DCX.
 		 	   		  

Re: ld for VMS?

[Tristan Gingold]

On May 3, 2010, at 10:16 AM, Jay K wrote:

> 
> Thanks. Very helpful.
> Maybe the assert before failing should print "try library /data=expand foo.olb" or such?

Well, I think there are no real reason why bfd can't deal with compressed libs.  I will try to investigate
that.

> Oddly, running that command over all files seems like a bad idea:
>   I got something "unable to read symbols from starlet.olb". I lost the message.
>   I replaced startlet.olb with a pristine copy and now just:
> 
>  /usr/local/lib/gcc/alpha-dec-vms/4_5_0/pcrt0.o:($DATA$+0x90): undefined reference to `lib$establish'

Looks like pcrt0 was not correctly compiled.  IIRC, the current version must be compiled with DEC-C.
I think you could compile it with gcc provided you remove the condition handler.  We have done such
a change here and we plan to submit it.

> Looks like maybe I only have the older vaxc$establish in my libraries.

>  I am only on 7.x not the current 8.x. The admin is interested in upgrading when he has time.
> Maybe I should edit pcrt0.c. I'll look.

Yes.

Tristan.

RE: ld for VMS?

[Jay K]

arg..I'm not sure where I got my crt0.o from. I'm sure I compiled it myself, somehow.
When I tried compiling it with cc just now, and copied to Mac host, alpha-dec-vms-gcc/ld complain it doesn't know the format.
/usr/local/lib/gcc/alpha-dec-vms/4_5_0/pcrt0.o: file not recognized: File format not recognized

There is also the problem with 64bit crt0.c that it uses pragma pointer_size.

 - Jay

----------------------------------------
> Subject: Re: ld for VMS?
> From: gingold@adacore.com
> Date: Mon, 3 May 2010 10:31:49 +0200
> CC: becker.ismaning@freenet.de; rupp@gnat.com; binutils@sourceware.org
> To: jay.krell@cornell.edu
>
>
> On May 3, 2010, at 10:16 AM, Jay K wrote:
>
>>
>> Thanks. Very helpful.
>> Maybe the assert before failing should print "try library /data=expand foo.olb" or such?
>
> Well, I think there are no real reason why bfd can't deal with compressed libs. I will try to investigate
> that.
>
>> Oddly, running that command over all files seems like a bad idea:
>> I got something "unable to read symbols from starlet.olb". I lost the message.
>> I replaced startlet.olb with a pristine copy and now just:
>>
>> /usr/local/lib/gcc/alpha-dec-vms/4_5_0/pcrt0.o:($DATA$+0x90): undefined reference to `lib$establish'
>
> Looks like pcrt0 was not correctly compiled. IIRC, the current version must be compiled with DEC-C.
> I think you could compile it with gcc provided you remove the condition handler. We have done such
> a change here and we plan to submit it.
>
>> Looks like maybe I only have the older vaxc$establish in my libraries.
>
>> I am only on 7.x not the current 8.x. The admin is interested in upgrading when he has time.
>> Maybe I should edit pcrt0.c. I'll look.
>
> Yes.
>
> Tristan.
>
 		 	   		  

Re: ld for VMS?

[Tristan Gingold]

On Apr 26, 2010, at 6:39 PM, h.becker wrote:

> Tristan Gingold wrote:
>> On Apr 26, 2010, at 2:05 PM, becker.ismaning@freenet.de wrote:
>>>  Hmm, third(?) attempt to get this through.
>> Got it!
>>> Usually,  ACLEDTSHR is the first member in imagelib.olb, the shareable image libary. VMS ships this library "expanded". But you can "reduce" such libraries with the /data qualifier. For VMS libraries "compressed" means to remove unused blocks from deleted modules.
>> Ah, ah.  So I can try to reproduce the issue by using /data.  I suppose DCX was also involved, don't I ?
>> Tristan.
> 
> Yes, "reduce" and "expand" is implemented with DCX.

Ok, I can reproduce the issue and I am investigating.

Tristan.

RE: ld for VMS?

[Jay K]

ok, having edited down vms-crt0.c to remove the handler/establish and compile it with cross gcc, cross gcc+ld work, I copied hello.exe to VMS system and it works!
Thanks!
Why is the handler incompatible with gcc? Ah..maybe cc treats lib$establish as a special builtin function?
Now to try cross building bigger stuff like cvs, ld, gcc.. :)
It seems editing vms-crt0.c down might introduce some small malfunction.
We'll see.

 - Jay


----------------------------------------
> From: jay.krell@cornell.edu
> To: gingold@adacore.com
> CC: becker.ismaning@freenet.de; rupp@gnat.com; binutils@sourceware.org
> Subject: RE: ld for VMS?
> Date: Mon, 3 May 2010 08:56:53 +0000
>
>
> arg..I'm not sure where I got my crt0.o from. I'm sure I compiled it myself, somehow.
> When I tried compiling it with cc just now, and copied to Mac host, alpha-dec-vms-gcc/ld complain it doesn't know the format.
> /usr/local/lib/gcc/alpha-dec-vms/4_5_0/pcrt0.o: file not recognized: File format not recognized
>
> There is also the problem with 64bit crt0.c that it uses pragma pointer_size.
>
>  - Jay
>
> ----------------------------------------
>> Subject: Re: ld for VMS?
>> From: gingold@adacore.com
>> Date: Mon, 3 May 2010 10:31:49 +0200
>> CC: becker.ismaning@freenet.de; rupp@gnat.com; binutils@sourceware.org
>> To: jay.krell@cornell.edu
>>
>>
>> On May 3, 2010, at 10:16 AM, Jay K wrote:
>>
>>>
>>> Thanks. Very helpful.
>>> Maybe the assert before failing should print "try library /data=expand foo.olb" or such?
>>
>> Well, I think there are no real reason why bfd can't deal with compressed libs. I will try to investigate
>> that.
>>
>>> Oddly, running that command over all files seems like a bad idea:
>>> I got something "unable to read symbols from starlet.olb". I lost the message.
>>> I replaced startlet.olb with a pristine copy and now just:
>>>
>>> /usr/local/lib/gcc/alpha-dec-vms/4_5_0/pcrt0.o:($DATA$+0x90): undefined reference to `lib$establish'
>>
>> Looks like pcrt0 was not correctly compiled. IIRC, the current version must be compiled with DEC-C.
>> I think you could compile it with gcc provided you remove the condition handler. We have done such
>> a change here and we plan to submit it.
>>
>>> Looks like maybe I only have the older vaxc$establish in my libraries.
>>
>>> I am only on 7.x not the current 8.x. The admin is interested in upgrading when he has time.
>>> Maybe I should edit pcrt0.c. I'll look.
>>
>> Yes.
>>
>> Tristan.
>>
>
 		 	   		  

Re: ld for VMS?

[Tristan Gingold]

On May 3, 2010, at 11:21 AM, Jay K wrote:

> 
> ok, having edited down vms-crt0.c to remove the handler/establish and compile it with cross gcc, cross gcc+ld work, I copied hello.exe to VMS system and it works!

Congrats!

> Thanks!
> Why is the handler incompatible with gcc? Ah..maybe cc treats lib$establish as a special builtin function?

Right, that's it.  For DEC-C, lib$establish is an intrinsic.

> Now to try cross building bigger stuff like cvs, ld, gcc.. :)

Good luck.  How do you handle the include issue ?  Ie, do you have the VMS specific includes ?

> It seems editing vms-crt0.c down might introduce some small malfunction.

No, the lib$establish stuff was not necessary.

NB: for gcc specific issues, you'd better to post on gcc@gcc.gnu.org

Tristan.

RE: ld for VMS?

[Jay K]

This is why I thought so:

http://h71000.www7.hp.com/doc/83final/5763/5763pro_069.html

To cause an OpenVMS exception to generate a UNIX style signal, user exception handlers must return SS$_RESIGNAL  upon receiving any exception that they do not want to handle. Returning SS$_NORMAL  prevents the generation of a UNIX style signal. UNIX signals are generated as if by an exception handler in the stack frame of the main C program. Not all OpenVMS exceptions correspond to UNIX signals. See Chapter 4 for more information on the interaction of OpenVMS exceptions and UNIX style signals.

Though that doesn't say what happens if there is no handler, only what handlers should do.

> NB: for gcc specific issues, you'd better to post on gcc@gcc.gnu.org

Right, sorry. They are imho very intermingled and my original query was for an ld. Granted, we got way past that a while ago: "use head".

> Good luck. How do you handle the include issue ? Ie, do you have the VMS specific includes ?

Same way I got hello world to work (since it had an #include and uses libraries).
Yes. I have /usr/local/alpha-dec-vms/lib and /usr/local/alpha-dec-vms/include, contents
copied from the VMS machine, the libraries/olbs or at least some converted/expanded/compressed, the headers hacked
slightly with #define __int64 long long.
I don't "like" this, but it is the way.
Among other things -- which files to copy?
I end up copying surely way too much.


I don't get too far yet..there is something wierd with memcpy.
Compiling libiberty/regex.c as part of gcc says wrong number of parameters.
I have to look more closely.
I swear removing the space after one instance of memcpy helped, but not the other.
memcpy is a macro:
#define memcpy(a, b, c) __MEMCPY(...stuff...)


There is still something wierd where GNU ld doesn't like .obj files output by VMS cc.
In particular, vms-crt0.c cannot actually be compiled by VMS cc, nor out of the box by gcc.


 - Jay

----------------------------------------
> Subject: Re: ld for VMS?
> From: gingold@adacore.com
> Date: Mon, 3 May 2010 11:32:21 +0200
> CC: becker.ismaning@freenet.de; rupp@gnat.com; binutils@sourceware.org
> To: jay.krell@cornell.edu
>
>
> On May 3, 2010, at 11:21 AM, Jay K wrote:
>
>>
>> ok, having edited down vms-crt0.c to remove the handler/establish and compile it with cross gcc, cross gcc+ld work, I copied hello.exe to VMS system and it works!
>
> Congrats!
>
>> Thanks!
>> Why is the handler incompatible with gcc? Ah..maybe cc treats lib$establish as a special builtin function?
>
> Right, that's it. For DEC-C, lib$establish is an intrinsic.
>
>> Now to try cross building bigger stuff like cvs, ld, gcc.. :)
>
> Good luck. How do you handle the include issue ? Ie, do you have the VMS specific includes ?
>
>> It seems editing vms-crt0.c down might introduce some small malfunction.
>
> No, the lib$establish stuff was not necessary.
>
> NB: for gcc specific issues, you'd better to post on gcc@gcc.gnu.org
>
> Tristan.
>
 		 	   		  

Re: ld for VMS?

[Tristan Gingold]

On May 3, 2010, at 12:13 PM, Jay K wrote:

> 
> This is why I thought so:
> 
> http://h71000.www7.hp.com/doc/83final/5763/5763pro_069.html
> 
> To cause an OpenVMS exception to generate a UNIX style signal, user exception handlers must return SS$_RESIGNAL  upon receiving any exception that they do not want to handle. Returning SS$_NORMAL  prevents the generation of a UNIX style signal. UNIX signals are generated as if by an exception handler in the stack frame of the main C program. Not all OpenVMS exceptions correspond to UNIX signals. See Chapter 4 for more information on the interaction of OpenVMS exceptions and UNIX style signals.
> 
> Though that doesn't say what happens if there is no handler, only what handlers should do.

The handler is installed by decc$crtl_init using a global vector.  Thus the condition handler for
main is not required.  Of course, other user condition handlers should return SS$_RESIGNAL on condition
that they don't handle.

(But this is more a gcc topic!)

>> NB: for gcc specific issues, you'd better to post on gcc@gcc.gnu.org
> 
> Right, sorry. They are imho very intermingled and my original query was for an ld. Granted, we got way past that a while ago: "use head".
> 
>> Good luck. How do you handle the include issue ? Ie, do you have the VMS specific includes ?
> 
> Same way I got hello world to work (since it had an #include and uses libraries).
> Yes. I have /usr/local/alpha-dec-vms/lib and /usr/local/alpha-dec-vms/include, contents
> copied from the VMS machine, the libraries/olbs or at least some converted/expanded/compressed, the headers hacked
> slightly with #define __int64 long long.
> I don't "like" this, but it is the way.
> Among other things -- which files to copy?
> I end up copying surely way too much.

I think that's it.

> I don't get too far yet..there is something wierd with memcpy.
> Compiling libiberty/regex.c as part of gcc says wrong number of parameters.
> I have to look more closely.
> I swear removing the space after one instance of memcpy helped, but not the other.
> memcpy is a macro:
> #define memcpy(a, b, c) __MEMCPY(...stuff...)

I haven't hit this issue (yet ?)

> There is still something wierd where GNU ld doesn't like .obj files output by VMS cc.
> In particular, vms-crt0.c cannot actually be compiled by VMS cc, nor out of the box by gcc.

How do you copy from VMS to unix ?

Tristan.

RE: ld for VMS?

[Jay K]

The memcpy problem was #define __size_t. Moving along.. :)


 > decc$crtl_init

Presumably related to decc$main? I'll check the docs.

> how do I copy


The VMS machine has a web server, just serving out a directory, it lists files, I click
on them, they download. I've tried bare .obj files and .zips.
The .zips certainly work in general since that's how I got the headers and libraries.
I could use .tar.gz also but haven't been.


To copy to VMS (hello.exe) I use sftp.
sftp might also work to copy from VMS, though the one time I tried it exited, not sure if it was before
or after the copy.


For some reason scp isn't working, which is what I'd normally use.
 It complains about an extra newline or such.
 
I can also probably email uuencoded files.

If I'm really successful on this project, maybe I can get a working cross-built openssh/scp..


Given the handler isn't needed, I'm fine with gcc-built crt0.c.
Presumably the patch is either to remove the handler and just compile with gcc, or #ifdef __GNUC__ around it.
And then update the makefile chunks.

alpha64-dec-vms has additional problems because of the pointer size stuff, though I don't get it.
If the pointers are indeed 32bits, declare that they are ints and extend them to long, and pass long
pointers to main (assuming main is compiled with gcc..and assuming gcc doesn't do something
funny for main). I don't see why the copying is done.

Thanks,
 - Jay

----------------------------------------
> Subject: Re: ld for VMS?
> From: gingold@adacore.com
> Date: Mon, 3 May 2010 12:53:53 +0200
> CC: becker.ismaning@freenet.de; rupp@gnat.com; binutils@sourceware.org
> To: jay.krell@cornell.edu
>
>
> On May 3, 2010, at 12:13 PM, Jay K wrote:
>
>>
>> This is why I thought so:
>>
>> http://h71000.www7.hp.com/doc/83final/5763/5763pro_069.html
>>
>> To cause an OpenVMS exception to generate a UNIX style signal, user exception handlers must return SS$_RESIGNAL upon receiving any exception that they do not want to handle. Returning SS$_NORMAL prevents the generation of a UNIX style signal. UNIX signals are generated as if by an exception handler in the stack frame of the main C program. Not all OpenVMS exceptions correspond to UNIX signals. See Chapter 4 for more information on the interaction of OpenVMS exceptions and UNIX style signals.
>>
>> Though that doesn't say what happens if there is no handler, only what handlers should do.
>
> The handler is installed by decc$crtl_init using a global vector. Thus the condition handler for
> main is not required. Of course, other user condition handlers should return SS$_RESIGNAL on condition
> that they don't handle.
>
> (But this is more a gcc topic!)
>
>>> NB: for gcc specific issues, you'd better to post on gcc@gcc.gnu.org
>>
>> Right, sorry. They are imho very intermingled and my original query was for an ld. Granted, we got way past that a while ago: "use head".
>>
>>> Good luck. How do you handle the include issue ? Ie, do you have the VMS specific includes ?
>>
>> Same way I got hello world to work (since it had an #include and uses libraries).
>> Yes. I have /usr/local/alpha-dec-vms/lib and /usr/local/alpha-dec-vms/include, contents
>> copied from the VMS machine, the libraries/olbs or at least some converted/expanded/compressed, the headers hacked
>> slightly with #define __int64 long long.
>> I don't "like" this, but it is the way.
>> Among other things -- which files to copy?
>> I end up copying surely way too much.
>
> I think that's it.
>
>> I don't get too far yet..there is something wierd with memcpy.
>> Compiling libiberty/regex.c as part of gcc says wrong number of parameters.
>> I have to look more closely.
>> I swear removing the space after one instance of memcpy helped, but not the other.
>> memcpy is a macro:
>> #define memcpy(a, b, c) __MEMCPY(...stuff...)
>
> I haven't hit this issue (yet ?)
>
>> There is still something wierd where GNU ld doesn't like .obj files output by VMS cc.
>> In particular, vms-crt0.c cannot actually be compiled by VMS cc, nor out of the box by gcc.
>
> How do you copy from VMS to unix ?
>
> Tristan.
>
 		 	   		  

Re: ld for VMS?

[Tristan Gingold]

On May 3, 2010, at 1:16 PM, Jay K wrote:

> 
> The memcpy problem was #define __size_t. Moving along.. :)

Ok.

>  > decc$crtl_init
> 
> Presumably related to decc$main? I'll check the docs.

Yes, but I am not sure this is documented.  Calling decc$main should make it.

>> how do I copy

> The VMS machine has a web server, just serving out a directory, it lists files, I click
> on them, they download. I've tried bare .obj files and .zips.
> The .zips certainly work in general since that's how I got the headers and libraries.
> I could use .tar.gz also but haven't been.

I haven't tested http.  I use ftp.  I think that zip should work too (for .obj).

> To copy to VMS (hello.exe) I use sftp.
> sftp might also work to copy from VMS, though the one time I tried it exited, not sure if it was before
> or after the copy.

I haven't tested sftp.  Note that only transferring .obj is difficult, .exe and text files work well 
(according to my experience).

> For some reason scp isn't working, which is what I'd normally use.
>  It complains about an extra newline or such.
>  
> I can also probably email uuencoded files.
> 
> If I'm really successful on this project, maybe I can get a working cross-built openssh/scp..
> 
> 
> Given the handler isn't needed, I'm fine with gcc-built crt0.c.
> Presumably the patch is either to remove the handler and just compile with gcc, or #ifdef __GNUC__ around it.
> And then update the makefile chunks.
> 
> alpha64-dec-vms has additional problems because of the pointer size stuff, though I don't get it.
> If the pointers are indeed 32bits, declare that they are ints and extend them to long, and pass long
> pointers to main (assuming main is compiled with gcc..and assuming gcc doesn't do something
> funny for main). I don't see why the copying is done.

Here we are only interested in alpha64-dec-vms, which is more difficult due to pointer size.
But you need copying for argv[] because it's an array of pointer.

Tristan.

Re: ld for VMS?

[Tim Sneddon]

On 3/05/2010 9:43 PM, Tristan Gingold wrote:
> 
> On May 3, 2010, at 3:41 PM, Tim Sneddon wrote:
> 
>> On 3/05/2010 8:27 PM, Tristan Gingold wrote:
>>>
>>> On May 3, 2010, at 1:16 PM, Jay K wrote:
>>>
>>>>
>>>> The memcpy problem was #define __size_t. Moving along.. :)
>>>
>>> Ok.
>>>
>>>>> decc$crtl_init
>>>>
>>>> Presumably related to decc$main? I'll check the docs.
>>>
>>> Yes, but I am not sure this is documented.  Calling decc$main should make it.
>>>
>>
>> DECC$CRTL_INIT is supported and documented here:
>>
>>     http://h71000.www7.hp.com/doc/83final/5763/5763pro_028.html#decc_crtl_init_routine
>>
>> The example provided shows the routine being called from Pascal.
> 
> Right.  But what is not documented is decc$main, which calls decc$crtl_init.
> 

Good point, I misunderstood.  I also cleverly sent the mail to you
only, and not the list.

The prototype for DECC$MAIN looks something like this:

 void decc$main(void *arg1,
                void *arg2,
                void *arg3,
                IFD *image_file_desc,  /* Ptr to image file descriptor block */
                                       /*  returned by image activator.      */
                void *arg5,
                void *arg6,
                int *argc,             /* Ptr to returned argument count */
                void **argv,           /* Ptr to returned argument vector */
                void **envp);          /* Ptr to returned environment vector */

You can see the layout for IFD in <ifddef.h>, found in the text
library, SYS$LIBRARY:SYS$LIB_C.TLB.

The image file descriptor is argument 4 of the 6 arguments passed
to the user image by the $IMGSTA service.

Tim.

RE: ld for VMS?

[Jay K]

[top posting because it so much easier...]

Tristan, why do you say transferring .obj is difficult? I maybe agree -- I can't seem to do it -- but I wonder what your experience was, to maybe fix mine.
Ah, I see what you mean about argv needing to be copied..but I still think it can done without the #pragmas. Albeit, it'd be ugly -- heavy use of int, long long, and casting. I'll post something to gcc@ later...well..er..I'm really not actively looking at alpha64-dec-vms right now..

I think "we" need either a significant addition to gcc to deal with "prefixes", or something somewhere like, like in libgcc:

/*
https://www.slac.stanford.edu/exp/glast/flight/doxygen/SVC/binary/PBI/dev/linux-gcc/doc_gather/dox/html/Alias_8h_8xx-xxx-gcc.html
but no, instead:
http://sourceware.org/binutils/docs-2.20/as/Weakref.html#Weakref
*/

#define ALIAS(name, prefix) \
asm (".weakref " prefix #name "," #name);

#define DECC(name) ALIAS(name, "decc$")

DECC(__MEMSET)
DECC(__assert)
DECC(__posix__exit)
... lots ...

I'll report more to gcc@ if/when I have it working.
asis, I get lots of unresolved symbols linking e.g. cvs.

 - Jay


----------------------------------------
> Subject: Re: ld for VMS?
> From: gingold@adacore.com
> Date: Mon, 3 May 2010 14:27:55 +0200
> CC: becker.ismaning@freenet.de; rupp@gnat.com; binutils@sourceware.org
> To: jay.krell@cornell.edu
>
>
> On May 3, 2010, at 1:16 PM, Jay K wrote:
>
>>
>> The memcpy problem was #define __size_t. Moving along.. :)
>
> Ok.
>
>>> decc$crtl_init
>>
>> Presumably related to decc$main? I'll check the docs.
>
> Yes, but I am not sure this is documented. Calling decc$main should make it.
>
>>> how do I copy
>
>> The VMS machine has a web server, just serving out a directory, it lists files, I click
>> on them, they download. I've tried bare .obj files and .zips.
>> The .zips certainly work in general since that's how I got the headers and libraries.
>> I could use .tar.gz also but haven't been.
>
> I haven't tested http. I use ftp. I think that zip should work too (for .obj).
>
>> To copy to VMS (hello.exe) I use sftp.
>> sftp might also work to copy from VMS, though the one time I tried it exited, not sure if it was before
>> or after the copy.
>
> I haven't tested sftp. Note that only transferring .obj is difficult, .exe and text files work well
> (according to my experience).
>
>> For some reason scp isn't working, which is what I'd normally use.
>> It complains about an extra newline or such.
>>
>> I can also probably email uuencoded files.
>>
>> If I'm really successful on this project, maybe I can get a working cross-built openssh/scp..
>>
>>
>> Given the handler isn't needed, I'm fine with gcc-built crt0.c.
>> Presumably the patch is either to remove the handler and just compile with gcc, or #ifdef __GNUC__ around it.
>> And then update the makefile chunks.
>>
>> alpha64-dec-vms has additional problems because of the pointer size stuff, though I don't get it.
>> If the pointers are indeed 32bits, declare that they are ints and extend them to long, and pass long
>> pointers to main (assuming main is compiled with gcc..and assuming gcc doesn't do something
>> funny for main). I don't see why the copying is done.
>
> Here we are only interested in alpha64-dec-vms, which is more difficult due to pointer size.
> But you need copying for argv[] because it's an array of pointer.
>
> Tristan.
>
 		 	   		  

Re: ld for VMS?

[h.becker]

Jay K wrote:
> Tristan, why do you say transferring .obj is difficult? I maybe agree -- I can't seem to do it -- but I wonder what your experience was, to maybe fix mine.
This applies to Alpha and VAX object files: because the record structure 
is lost during ftp-style transfers. A binary transfer from Linux/Unix to 
VMS creates a fixed record structure on VMS. That's wrong, it is a 
variable length record structur. A binary transfer from VMS to 
Linux/Unix transfers the data of the records not the length fields. So 
you have to have some pre- or postprocessing on the VMS side. And you 
can't avoid this with an archiver.

Hartmut

Re: ld for VMS?

[Tristan Gingold]

On May 4, 2010, at 11:14 AM, h.becker wrote:

> Jay K wrote:
>> Tristan, why do you say transferring .obj is difficult? I maybe agree -- I can't seem to do it -- but I wonder what your experience was, to maybe fix mine.
> This applies to Alpha and VAX object files: because the record structure is lost during ftp-style transfers. A binary transfer from Linux/Unix to VMS creates a fixed record structure on VMS. That's wrong, it is a variable length record structur.

Right.

> A binary transfer from VMS to Linux/Unix transfers the data of the records not the length fields. So you have to have some pre- or postprocessing on the VMS side. And you can't avoid this with an archiver.

Except that with Alpha-VMS the length fields are duplicated within the records.  BFD is able to handle
Alpha obj files without the record length RMS field.  Things are harder with VAX obj files!

As I said, I usually transfer from VMS using ftp.  I was able to transfer to VMS using ar on unix and
librarian on vms.

Tristan.

Re: ld for VMS?

[h.becker]

Tristan Gingold wrote:
> The handler is installed by decc$crtl_init using a global vector.  Thus the condition handler for
> main is not required.  Of course, other user condition handlers should return SS$_RESIGNAL on condition
> that they don't handle.
> 
> (But this is more a gcc topic!)
I'mnot sure what is meant by using a global vector. VMS has primary and 
secondary exception handlers, they are for the debugger and friends. If 
present, they are called before any frame based handler is looked up. 
SS$_RESIGNAL is what a frame based handler is supposed to return, if the 
handler can't handle the exception. If none of the frame based handler 
can handle an exception last chance handlers are called. That's probably 
what is meant, here. But I haven't checked what decc$main or 
decc$crtl_init do. The manual says, that on VAX decc$crtl_init 
establishes a frame based handler for its caller. That's not that easy 
for Alpha, because Alpha has only static handlers. So there is very 
likely a different mechanism which may be a last chance handler.

How lib$establish (and lib$revert) actually enable dynamic handlers is a 
different thing. It requires compiler support (to add a static handler).

Hartmut

Re: ld for VMS?

[Tristan Gingold]

On May 4, 2010, at 11:34 AM, h.becker wrote:

> Tristan Gingold wrote:
>> The handler is installed by decc$crtl_init using a global vector.  Thus the condition handler for
>> main is not required.  Of course, other user condition handlers should return SS$_RESIGNAL on condition
>> that they don't handle.
>> (But this is more a gcc topic!)
> I'mnot sure what is meant by using a global vector. VMS has primary and secondary exception handlers, they are for the debugger and friends. If present, they are called before any frame based handler is looked up. SS$_RESIGNAL is what a frame based handler is supposed to return, if the handler can't handle the exception. If none of the frame based handler can handle an exception last chance handlers are called. That's probably what is meant, here. But I haven't checked what decc$main or decc$crtl_init do. The manual says, that on VAX decc$crtl_init establishes a frame based handler for its caller. That's not that easy for Alpha, because Alpha has only static handlers. So there is very likely a different mechanism which may be a last chance handler.

Right, it uses a last chance handler.

> How lib$establish (and lib$revert) actually enable dynamic handlers is a different thing. It requires compiler support (to add a static handler).

Sure.

Tristan.

Re: ld for VMS?

[h.becker]

Tristan Gingold wrote:
> Except that with Alpha-VMS the length fields are duplicated within the records.  BFD is able to handle
> Alpha obj files without the record length RMS field.  Things are harder with VAX obj files!
Hmm, if BFD reads binaray files without the RMS record structure, how 
are they stored in an ar library? With or without the RMS record 
structure? And what is in a file which contains an extracted object 
module from an archive, RMS record structures?

> As I said, I usually transfer from VMS using ftp.  I was able to transfer to VMS using ar on unix and
> librarian on vms.
Sorry, I should have said that I mean the archivers tar, gzip and friends.

Hartmut

Re: ld for VMS?

[Tristan Gingold]

On May 4, 2010, at 11:45 AM, h.becker wrote:

> Tristan Gingold wrote:
>> Except that with Alpha-VMS the length fields are duplicated within the records.  BFD is able to handle
>> Alpha obj files without the record length RMS field.  Things are harder with VAX obj files!
> Hmm, if BFD reads binaray files without the RMS record structure, how are they stored in an ar library? With or without the RMS record structure?

Yes, with the RMS record structures (otherwise it won't be readable from VMS).

> And what is in a file which contains an extracted object module from an archive, RMS record structures?

Yes, with the RMS record structures.  BFD always write with RMS record structures, but it can read without
them.

Tristan.

Re: ld for VMS?

[Tristan Gingold]

On Apr 26, 2010, at 1:01 PM, Douglas B Rupp wrote:

> Tristan Gingold wrote:
>> On Apr 25, 2010, at 8:11 PM, Jay K wrote:
>>> Tristan,
>>>  I'm seeing the following:
>>>  Any alpha-dec-vms-ld invocation with reasonable inputs fails an assertion:
>>>   alpha-dec-vms-ld: BFD (GNU Binutils) 2.20.51.20100425 assertion fail /src/binutils/src/bfd/vms-lib.c:351
>>>          BFD_ASSERT (sbm_sz>= sizeof (struct vms_dcxsbm) + l + 3 * sbm_len);
>>> in _bfd_vms_lib_archive_p. I'm not sure it is complaining about gas output or the libraries from VMS.
>> This is an error due to a compressed library from VMS.  Maybe starlet ?
>>> (gdb) p *abfd  $1 = {
>>>  id = 6,   filename = 0x80ed54 "ACLEDTSHR", 
>> And more precisely the member ACLEDTSHR.
> 
> It could be a shareable image library, not an object library. It will contain only a symbol table and a pointer to the .exe. ACLEDTSHR sounds like a shareable image to me.

Maybe.  But IIRC, shareable image were not compressed.

Re: ld for VMS?

[Douglas B Rupp]

Tristan Gingold wrote:
> On Apr 25, 2010, at 8:11 PM, Jay K wrote:
> 
>> Tristan,
>>   I'm seeing the following:
>>   Any alpha-dec-vms-ld invocation with reasonable inputs fails an assertion:
>>    alpha-dec-vms-ld: BFD (GNU Binutils) 2.20.51.20100425 assertion fail /src/binutils/src/bfd/vms-lib.c:351
>>           BFD_ASSERT (sbm_sz>= sizeof (struct vms_dcxsbm) + l + 3 * sbm_len);
>>  in _bfd_vms_lib_archive_p. I'm not sure it is complaining about gas output or the libraries from VMS.
> 
> This is an error due to a compressed library from VMS.  Maybe starlet ?
> 
>> (gdb) p *abfd  
>> $1 = {
>>   id = 6, 
>>   filename = 0x80ed54 "ACLEDTSHR", 
> 
> And more precisely the member ACLEDTSHR.
> 

It could be a shareable image library, not an object library. It will 
contain only a symbol table and a pointer to the .exe. ACLEDTSHR sounds 
like a shareable image to me.

Re: ld for VMS?

[Tristan Gingold]

On Apr 25, 2010, at 9:24 PM, Jay K wrote:

> 
> Douglas, thank you, that seems to help.
> 
> Without set file attr:
> 
> WALLIS> link Wr.mo
> %LINK-W-RECTYP, file USER$DISK:[JAYKRELL.CM3-BOOT-ALPHA32_VMS-1]WR.MO;1 record 1 is illegal (90.)
> %LINK-W-RECTYP, file USER$DISK:[JAYKRELL.CM3-BOOT-ALPHA32_VMS-1]WR.MO;1 record 2 is illegal (2048.)
> 
> With set file attr:
> 
> WALLIS> link char.mo
> %LINK-W-NUDFSYMS, 3 undefined symbols:
> %LINK-I-UDFSYM,     Char_I3 
> %LINK-I-UDFSYM,     RTHooks_I3 
> %LINK-I-UDFSYM,     Word_I3 
> %LINK-W-USEUNDEF, undefined symbol Char_I3 referenced
>     in psect $DATA$ offset %X00000090
>     in module CHAR file USER$DISK:[JAYKRELL.CM3-BOOT-ALPHA32_VMS-1]CHAR.MO;1
> 
> That isn't supposed to have succeeded, it's just one .obj among a bunch.
> But at least the errors make more sense.
> 
> I know VMS file system is "different", but I don't know enough to know what to do about it. :)
> VMS users (you and the sysadmin) are very quick to suggest things that sounds very
> easy to them but I have no idea where the supply of these suggestions is. :)
> 
> Something is still off doing a cross link.
> Also I noticed some configure.com, makefile.vms strewn around, but they seem to be partly out of date.
> I also see Tristan rewrote some of the stuff recently, so not all out of date.

Indeed, I haven't yet updated bfd/makefile.vms after my recent changes.  I plan to do that.

Tristan.

Re: ld for VMS?

[Tristan Gingold]

On Apr 25, 2010, at 8:11 PM, Jay K wrote:

> 
> Tristan,
>   I'm seeing the following:
>   Any alpha-dec-vms-ld invocation with reasonable inputs fails an assertion:
>    alpha-dec-vms-ld: BFD (GNU Binutils) 2.20.51.20100425 assertion fail /src/binutils/src/bfd/vms-lib.c:351
>           BFD_ASSERT (sbm_sz>= sizeof (struct vms_dcxsbm) + l + 3 * sbm_len);
>  in _bfd_vms_lib_archive_p. I'm not sure it is complaining about gas output or the libraries from VMS.

This is an error due to a compressed library from VMS.  Maybe starlet ?

> (gdb) p *abfd  
> $1 = {
>   id = 6, 
>   filename = 0x80ed54 "ACLEDTSHR", 

And more precisely the member ACLEDTSHR.

> Any alpha-dec-vms-as output passed to link on VMS is rejected with lots of errors, invalid record types, invalid lengths, etc.

Ehh, you need to carefully transfer from UNIX to VMS.  See Doug reply.

> alpha-dec-vms-gcc -malpha-as output is not accepted by VMS "macro", lots of errors.

Correct.
 
> alpha-dec-vms-nm does accept alpha-dec-vms-as output.
> 
> Any ideas?
> 
> You see, I can generate assembly on a cross host. That seems to work.
> And then I can either assemble it on the cross host, copy to VMS, link on VMS,
> or I could copy the assembly to VMS, run macro and link on VMS.
> Or I could link on the cross host and just copy the executables to VMS.
> None of the three options seems to be working.
> 
> I'll have to poke around more..

The third one should work.  We were able to use it.
You can assemble on VMS but you need to build gas on VMS.
You can link on VMS, but you need to correctly set the attributes.

Tristan.

RE: ld for VMS?

[Jay K]

Douglas, thank you, that seems to help.

Without set file attr:

WALLIS> link Wr.mo
%LINK-W-RECTYP, file USER$DISK:[JAYKRELL.CM3-BOOT-ALPHA32_VMS-1]WR.MO;1 record 1 is illegal (90.)
%LINK-W-RECTYP, file USER$DISK:[JAYKRELL.CM3-BOOT-ALPHA32_VMS-1]WR.MO;1 record 2 is illegal (2048.)

With set file attr:

WALLIS> link char.mo
%LINK-W-NUDFSYMS, 3 undefined symbols:
%LINK-I-UDFSYM,     Char_I3 
%LINK-I-UDFSYM,     RTHooks_I3 
%LINK-I-UDFSYM,     Word_I3 
%LINK-W-USEUNDEF, undefined symbol Char_I3 referenced
    in psect $DATA$ offset %X00000090
    in module CHAR file USER$DISK:[JAYKRELL.CM3-BOOT-ALPHA32_VMS-1]CHAR.MO;1

That isn't supposed to have succeeded, it's just one .obj among a bunch.
But at least the errors make more sense.

I know VMS file system is "different", but I don't know enough to know what to do about it. :)
VMS users (you and the sysadmin) are very quick to suggest things that sounds very
easy to them but I have no idea where the supply of these suggestions is. :)

Something is still off doing a cross link.
Also I noticed some configure.com, makefile.vms strewn around, but they seem to be partly out of date.
I also see Tristan rewrote some of the stuff recently, so not all out of date.

Thanks,
 - Jay

----------------------------------------
> Date: Sun, 25 Apr 2010 11:28:24 -0700
> From: rupp@gnat.com
> To: jay.krell@cornell.edu
> CC: gingold@adacore.com; binutils@sourceware.org
> Subject: Re: ld for VMS?
>
> Objects on AVMS are a variable length file type, no such file type
> exists on Unix, it's just a byte stream. You may be running into this
> problem. Do this before you try to link on VMS:
>
> $ set file/attr=(rfm=var,rat=none) .obj
>
> Jay K wrote:
>> Tristan,
>> I'm seeing the following:
>> Any alpha-dec-vms-ld invocation with reasonable inputs fails an assertion:
>> alpha-dec-vms-ld: BFD (GNU Binutils) 2.20.51.20100425 assertion fail /src/binutils/src/bfd/vms-lib.c:351
>> BFD_ASSERT (sbm_sz>= sizeof (struct vms_dcxsbm) + l + 3 * sbm_len);
>> in _bfd_vms_lib_archive_p. I'm not sure it is complaining about gas output or the libraries from VMS.
>> Maybe I'll poke around.
>> When I run it under a debugger:
>>
>> $ gdb --args alpha-dec-vms-ld cm3-boot-ALPHA32_VMS-1/Makefile.mo
>> (gdb) r
>> Starting program: /usr/local/bin/alpha-dec-vms-ld cm3-boot-ALPHA32_VMS-1/Makefile.mo
>> Reading symbols for shared libraries +++. done
>> /usr/local/bin/alpha-dec-vms-ld: BFD (GNU Binutils) 2.20.51.20100425 assertion fail /src/binutils/src/bfd/vms-lib.c:351
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
>> 0x000562bf in vms_lib_dcx (vec=0x845a08, buf=0x0, nbytes=65536) at /src/binutils/src/bfd/vms-lib.c:616
>> 616 if (!(sbm->flags[offset>> 3] & (1 << (offset & 7))))
>>
>> up
>> up
>> (gdb) p *abfd
>> $1 = {
>> id = 6,
>> filename = 0x80ed54 "ACLEDTSHR",
>>
>>
>> Any alpha-dec-vms-as output passed to link on VMS is rejected with lots of errors, invalid record types, invalid lengths, etc.
>>
>> alpha-dec-vms-gcc -malpha-as output is not accepted by VMS "macro", lots of errors.
>>
>> alpha-dec-vms-nm does accept alpha-dec-vms-as output.
>>
>> Any ideas?
>>
>> You see, I can generate assembly on a cross host. That seems to work.
>> And then I can either assemble it on the cross host, copy to VMS, link on VMS,
>> or I could copy the assembly to VMS, run macro and link on VMS.
>> Or I could link on the cross host and just copy the executables to VMS.
>> None of the three options seems to be working.
>>
>> I'll have to poke around more..
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: jay.krell@cornell.edu
>>> To: gingold@adacore.com
>>> CC: binutils@sourceware.org
>>> Subject: RE: ld for VMS?
>>> Date: Thu, 22 Apr 2010 16:24:09 +0000
>>>
>>>
>>> Darn ok. Maybe your changes will be contributed upstream? I guess not.
>>> I'll try to cross build it then. I'm seeing new errors, building unwind stuff in libgcc.
>>> I'll try some different configurations, could be gcc configure saw the GNU as/ld and
>>> decided to provide more functionality.
>>> Yes I can see binutils trunk builds VMS ld, thanks. I had only tried the latest release.
>>> Maybe I should go past 4.5 for gcc too?
>>>
>>> I also had to hack the headers a bit, like ln -s . vms and
>>> #ifdef __GNUC__
>>> #ifndef __int64
>>> #define __int64 long long
>>> #endif
>>>
>>> Thanks,
>>> - Jay
>>>
>>> ----------------------------------------
>>>> Subject: Re: ld for VMS?
>>>> From: gingold@adacore.com
>>>> Date: Thu, 22 Apr 2010 17:35:15 +0200
>>>> CC: binutils@sourceware.org
>>>> To: jay.krell@cornell.edu
>>>>
>>>>
>>>> On Apr 22, 2010, at 5:27 PM, Jay K wrote:
>>>>
>>>>> Awesome!
>>>>> "Partly" as in?
>>>> So, partially. This is still work in progress. But I am able to link and run large programs (such as gcc).
>>>>
>>>>> I can do without shared objects, for one thing, at least for now.
>>>>> I can try trunk.
>>>> Use of shared objects work. But ld can't currently generate shared images.
>>>>
>>>>> gcc 4.5 seems to largely work for Alpha/vms "out of the box".
>>>>> At least to output assembly, I think for GNU as. (which I had already built/installed, so configure found it).
>>>> Right.
>>>>
>>>>> My larger goal is to cross build: gcc, bash, sed, awk, make, etc. enough so that I can build gcc natively, at least cc1.
>>>> Well, you'd better to forget that. If you want a native gcc, you'd better to build it via a cross compiler.
>>>>
>>>> We did native builds of gcc, but it requires a lot of adjustments in the scripts. Tedious work.
>>>>
>>>> Tristan.
>>
>>
>
 		 	   		  

Re: ld for VMS?

[Douglas B Rupp]

Objects on AVMS are a variable length file type, no such file type 
exists on Unix, it's just a byte stream.  You may be running into this 
problem.  Do this before you try to link on VMS:

$ set file/attr=(rfm=var,rat=none) <foo>.obj

Jay K wrote:
> Tristan,
>   I'm seeing the following:
>   Any alpha-dec-vms-ld invocation with reasonable inputs fails an assertion:
>    alpha-dec-vms-ld: BFD (GNU Binutils) 2.20.51.20100425 assertion fail /src/binutils/src/bfd/vms-lib.c:351
>           BFD_ASSERT (sbm_sz>= sizeof (struct vms_dcxsbm) + l + 3 * sbm_len);
>  in _bfd_vms_lib_archive_p. I'm not sure it is complaining about gas output or the libraries from VMS.
> Maybe I'll poke around.
> When I run it under a debugger:
> 
> $ gdb --args alpha-dec-vms-ld cm3-boot-ALPHA32_VMS-1/Makefile.mo
> (gdb) r
> Starting program: /usr/local/bin/alpha-dec-vms-ld cm3-boot-ALPHA32_VMS-1/Makefile.mo
> Reading symbols for shared libraries +++. done
> /usr/local/bin/alpha-dec-vms-ld: BFD (GNU Binutils) 2.20.51.20100425 assertion fail /src/binutils/src/bfd/vms-lib.c:351
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
> 0x000562bf in vms_lib_dcx (vec=0x845a08, buf=0x0, nbytes=65536) at /src/binutils/src/bfd/vms-lib.c:616
> 616              if (!(sbm->flags[offset>> 3] & (1 << (offset & 7))))
> 
> up
> up
> (gdb) p *abfd  
> $1 = {
>   id = 6, 
>   filename = 0x80ed54 "ACLEDTSHR", 
> 
> 
> Any alpha-dec-vms-as output passed to link on VMS is rejected with lots of errors, invalid record types, invalid lengths, etc.
> 
> alpha-dec-vms-gcc -malpha-as output is not accepted by VMS "macro", lots of errors.
> 
> alpha-dec-vms-nm does accept alpha-dec-vms-as output.
> 
> Any ideas?
> 
> You see, I can generate assembly on a cross host. That seems to work.
> And then I can either assemble it on the cross host, copy to VMS, link on VMS,
> or I could copy the assembly to VMS, run macro and link on VMS.
> Or I could link on the cross host and just copy the executables to VMS.
> None of the three options seems to be working.
> 
> I'll have to poke around more..
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell@cornell.edu
>> To: gingold@adacore.com
>> CC: binutils@sourceware.org
>> Subject: RE: ld for VMS?
>> Date: Thu, 22 Apr 2010 16:24:09 +0000
>>
>>
>> Darn ok. Maybe your changes will be contributed upstream? I guess not.
>> I'll try to cross build it then. I'm seeing new errors, building unwind stuff in libgcc.
>> I'll try some different configurations, could be gcc configure saw the GNU as/ld and
>> decided to provide more functionality.
>> Yes I can see binutils trunk builds VMS ld, thanks. I had only tried the latest release.
>> Maybe I should go past 4.5 for gcc too?
>>
>> I also had to hack the headers a bit, like ln -s . vms and
>> #ifdef __GNUC__
>> #ifndef __int64
>> #define __int64 long long
>> #endif
>>
>> Thanks,
>>  - Jay
>>
>> ----------------------------------------
>>> Subject: Re: ld for VMS?
>>> From: gingold@adacore.com
>>> Date: Thu, 22 Apr 2010 17:35:15 +0200
>>> CC: binutils@sourceware.org
>>> To: jay.krell@cornell.edu
>>>
>>>
>>> On Apr 22, 2010, at 5:27 PM, Jay K wrote:
>>>
>>>> Awesome!
>>>> "Partly" as in?
>>> So, partially. This is still work in progress. But I am able to link and run large programs (such as gcc).
>>>
>>>> I can do without shared objects, for one thing, at least for now.
>>>> I can try trunk.
>>> Use of shared objects work. But ld can't currently generate shared images.
>>>
>>>> gcc 4.5 seems to largely work for Alpha/vms "out of the box".
>>>> At least to output assembly, I think for GNU as. (which I had already built/installed, so configure found it).
>>> Right.
>>>
>>>> My larger goal is to cross build: gcc, bash, sed, awk, make, etc. enough so that I can build gcc natively, at least cc1.
>>> Well, you'd better to forget that. If you want a native gcc, you'd better to build it via a cross compiler.
>>>
>>> We did native builds of gcc, but it requires a lot of adjustments in the scripts. Tedious work.
>>>
>>> Tristan.
>  		 	   		  
> 

RE: ld for VMS?

[Jay K]

Tristan,
  I'm seeing the following:
  Any alpha-dec-vms-ld invocation with reasonable inputs fails an assertion:
   alpha-dec-vms-ld: BFD (GNU Binutils) 2.20.51.20100425 assertion fail /src/binutils/src/bfd/vms-lib.c:351
          BFD_ASSERT (sbm_sz>= sizeof (struct vms_dcxsbm) + l + 3 * sbm_len);
 in _bfd_vms_lib_archive_p. I'm not sure it is complaining about gas output or the libraries from VMS.
Maybe I'll poke around.
When I run it under a debugger:

$ gdb --args alpha-dec-vms-ld cm3-boot-ALPHA32_VMS-1/Makefile.mo
(gdb) r
Starting program: /usr/local/bin/alpha-dec-vms-ld cm3-boot-ALPHA32_VMS-1/Makefile.mo
Reading symbols for shared libraries +++. done
/usr/local/bin/alpha-dec-vms-ld: BFD (GNU Binutils) 2.20.51.20100425 assertion fail /src/binutils/src/bfd/vms-lib.c:351

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x000562bf in vms_lib_dcx (vec=0x845a08, buf=0x0, nbytes=65536) at /src/binutils/src/bfd/vms-lib.c:616
616              if (!(sbm->flags[offset>> 3] & (1 << (offset & 7))))

up
up
(gdb) p *abfd  
$1 = {
  id = 6, 
  filename = 0x80ed54 "ACLEDTSHR", 


Any alpha-dec-vms-as output passed to link on VMS is rejected with lots of errors, invalid record types, invalid lengths, etc.

alpha-dec-vms-gcc -malpha-as output is not accepted by VMS "macro", lots of errors.

alpha-dec-vms-nm does accept alpha-dec-vms-as output.

Any ideas?

You see, I can generate assembly on a cross host. That seems to work.
And then I can either assemble it on the cross host, copy to VMS, link on VMS,
or I could copy the assembly to VMS, run macro and link on VMS.
Or I could link on the cross host and just copy the executables to VMS.
None of the three options seems to be working.

I'll have to poke around more..

 - Jay

----------------------------------------
> From: jay.krell@cornell.edu
> To: gingold@adacore.com
> CC: binutils@sourceware.org
> Subject: RE: ld for VMS?
> Date: Thu, 22 Apr 2010 16:24:09 +0000
>
>
> Darn ok. Maybe your changes will be contributed upstream? I guess not.
> I'll try to cross build it then. I'm seeing new errors, building unwind stuff in libgcc.
> I'll try some different configurations, could be gcc configure saw the GNU as/ld and
> decided to provide more functionality.
> Yes I can see binutils trunk builds VMS ld, thanks. I had only tried the latest release.
> Maybe I should go past 4.5 for gcc too?
>
> I also had to hack the headers a bit, like ln -s . vms and
> #ifdef __GNUC__
> #ifndef __int64
> #define __int64 long long
> #endif
>
> Thanks,
>  - Jay
>
> ----------------------------------------
>> Subject: Re: ld for VMS?
>> From: gingold@adacore.com
>> Date: Thu, 22 Apr 2010 17:35:15 +0200
>> CC: binutils@sourceware.org
>> To: jay.krell@cornell.edu
>>
>>
>> On Apr 22, 2010, at 5:27 PM, Jay K wrote:
>>
>>>
>>> Awesome!
>>> "Partly" as in?
>>
>> So, partially. This is still work in progress. But I am able to link and run large programs (such as gcc).
>>
>>> I can do without shared objects, for one thing, at least for now.
>>> I can try trunk.
>>
>> Use of shared objects work. But ld can't currently generate shared images.
>>
>>> gcc 4.5 seems to largely work for Alpha/vms "out of the box".
>>> At least to output assembly, I think for GNU as. (which I had already built/installed, so configure found it).
>>
>> Right.
>>
>>> My larger goal is to cross build: gcc, bash, sed, awk, make, etc. enough so that I can build gcc natively, at least cc1.
>>
>> Well, you'd better to forget that. If you want a native gcc, you'd better to build it via a cross compiler.
>>
>> We did native builds of gcc, but it requires a lot of adjustments in the scripts. Tedious work.
>>
>> Tristan.
 		 	   		  

Re: ld for VMS?

[h.becker]

nm has some problems with gcc- and VMS-compiler-generated objects. I 
have some patches but aren't allowed to check them in, yet.

Hartmut

> On Apr 22, 2010, at 5:02 PM, Rayson Ho wrote:
> 
>> Off topic a bit -- what is the object file format of VMS?
> 
> It is called EOBJ.
> 
> 
>> I was
>> looking for an "nm" like utility.
> 
> I think nm works, at least partially.
> 
> Tristan.

Re: ld for VMS?

[Douglas B Rupp]

Ld for IVMS is another work in progress, but is nothing has been checked 
in to the repository yet.

Rayson Ho wrote:
> Thanks for the reply. So I guess I will try to compile nm on VMS.
> 
> And back to the ld topic -- how good is the IA64 VMS support?
> 
> Rayson
> 
> 
> 
> On Thu, Apr 22, 2010 at 10:05 AM, Tristan Gingold <gingold@adacore.com> wrote:
>> On Apr 22, 2010, at 5:02 PM, Rayson Ho wrote:
>>
>>> Off topic a bit -- what is the object file format of VMS?
>> It is called EOBJ.
>>
>>
>>> I was
>>> looking for an "nm" like utility.
>> I think nm works, at least partially.
>>
>> Tristan.
>>
>>
> 

Re: ld for VMS?

[Rayson Ho]

Thanks for the reply. So I guess I will try to compile nm on VMS.

And back to the ld topic -- how good is the IA64 VMS support?

Rayson



On Thu, Apr 22, 2010 at 10:05 AM, Tristan Gingold <gingold@adacore.com> wrote:
>
> On Apr 22, 2010, at 5:02 PM, Rayson Ho wrote:
>
>> Off topic a bit -- what is the object file format of VMS?
>
> It is called EOBJ.
>
>
>> I was
>> looking for an "nm" like utility.
>
> I think nm works, at least partially.
>
> Tristan.
>
>

RE: ld for VMS?

[Jay K]

Darn ok. Maybe your changes will be contributed upstream? I guess not.
I'll try to cross build it then. I'm seeing new errors, building unwind stuff in libgcc.
I'll try some different configurations, could be gcc configure saw the GNU as/ld and
decided to provide more functionality.
Yes I can see binutils trunk builds VMS ld, thanks. I had only tried the latest release.
Maybe I should go past 4.5 for gcc too?

I also had to hack the headers a bit, like ln -s . vms and
#ifdef __GNUC__
#ifndef __int64
#define __int64 long long
#endif

Thanks,
 - Jay

----------------------------------------
> Subject: Re: ld for VMS?
> From: gingold@adacore.com
> Date: Thu, 22 Apr 2010 17:35:15 +0200
> CC: binutils@sourceware.org
> To: jay.krell@cornell.edu
>
>
> On Apr 22, 2010, at 5:27 PM, Jay K wrote:
>
>>
>> Awesome!
>> "Partly" as in?
>
> So, partially. This is still work in progress. But I am able to link and run large programs (such as gcc).
>
>> I can do without shared objects, for one thing, at least for now.
>> I can try trunk.
>
> Use of shared objects work. But ld can't currently generate shared images.
>
>> gcc 4.5 seems to largely work for Alpha/vms "out of the box".
>> At least to output assembly, I think for GNU as. (which I had already built/installed, so configure found it).
>
> Right.
>
>> My larger goal is to cross build: gcc, bash, sed, awk, make, etc. enough so that I can build gcc natively, at least cc1.
>
> Well, you'd better to forget that. If you want a native gcc, you'd better to build it via a cross compiler.
>
> We did native builds of gcc, but it requires a lot of adjustments in the scripts. Tedious work.
>
> Tristan.
>
 		 	   		  

Re: ld for VMS?

[Tristan Gingold]

On Apr 22, 2010, at 5:27 PM, Jay K wrote:

> 
> Awesome!
> "Partly" as in?

So, partially.  This is still work in progress.  But I am able to link and run large programs (such as gcc).

> I can do without shared objects, for one thing, at least for now.
> I can try trunk.

Use of shared objects work.  But ld can't currently generate shared images.

> gcc 4.5 seems to largely work for Alpha/vms "out of the box".
>   At least to output assembly, I think for GNU as. (which I had already built/installed, so configure found it).

Right.

> My larger goal is to cross build: gcc, bash, sed, awk, make, etc. enough so that I can build gcc natively, at least cc1.

Well, you'd better to forget that.  If you want a native gcc, you'd better to build it via a cross compiler.

We did native builds of gcc, but it requires a lot of adjustments in the scripts.  Tedious work.

Tristan.

RE: ld for VMS?

[Jay K]

Awesome!
"Partly" as in?
I can do without shared objects, for one thing, at least for now.
I can try trunk.


gcc 4.5 seems to largely work for Alpha/vms "out of the box".
  At least to output assembly, I think for GNU as. (which I had already built/installed, so configure found it).


My larger goal is to cross build: gcc, bash, sed, awk, make, etc. enough so that I can build gcc natively, at least cc1.
I know there is GNV, but I don't have administrative access on the machine, maybe I can cajole the administrator
to install a newer version, what is there seems a bit flaky, and I think the system is only using ODS-2. Again,
maybe I can cajole the administrator.
Give my somewhat limited scenario "native build cc1", maybe ODS-2 will suffice.
Maybe I'll get my own machine.


Thanks,
 - Jay

----------------------------------------
> Subject: Re: ld for VMS?
> From: gingold@adacore.com
> Date: Thu, 22 Apr 2010 17:05:16 +0200
> CC: binutils@sourceware.org
> To: jay.krell@cornell.edu
>
>
> On Apr 22, 2010, at 4:58 PM, Jay K wrote:
>
>>
>> Anyone by chance working on ld targeting VMS/Alpha?
>
> It is partially done on the trunk.
>
>> I'm interested in having a cross toolset targeting VMS/Alpha.
>> gcc, gas, already build.
>> Small problem maybe with libgcc
>
> We do have a cross-gcc for VMS/Alpha, also being in beta state.
>
> Tristan.
>
 		 	   		  

Re: ld for VMS?

[Tristan Gingold]

On Apr 22, 2010, at 4:58 PM, Jay K wrote:

> 
> Anyone by chance working on ld targeting VMS/Alpha?

It is partially done on the trunk.

> I'm interested in having a cross toolset targeting VMS/Alpha.
>  gcc, gas, already build.
>  Small problem maybe with libgcc

We do have a cross-gcc for VMS/Alpha, also being in beta state.

Tristan.

Re: ld for VMS?

[Tristan Gingold]

On Apr 22, 2010, at 5:02 PM, Rayson Ho wrote:

> Off topic a bit -- what is the object file format of VMS?

It is called EOBJ.


> I was
> looking for an "nm" like utility.

I think nm works, at least partially.

Tristan.

Re: ld for VMS?

[Rayson Ho]

Off topic a bit -- what is the object file format of VMS? I was
looking for an "nm" like utility.

Rayson



On Thu, Apr 22, 2010 at 9:58 AM, Jay K <jay.krell@cornell.edu> wrote:
>
> Anyone by chance working on ld targeting VMS/Alpha?
> I'm interested in having a cross toolset targeting VMS/Alpha.
>  gcc, gas, already build.
>  Small problem maybe with libgcc
>
>
> Thanks,
>  - Jay
>

ld for VMS?

[Jay K]

Anyone by chance working on ld targeting VMS/Alpha?
I'm interested in having a cross toolset targeting VMS/Alpha.
 gcc, gas, already build.
 Small problem maybe with libgcc


Thanks,
 - Jay