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?


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


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