This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: ld for VMS?


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.
>
 		 	   		  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]