Keyboard Shortcuts
Likes
- H390-Vm
- Messages
Search
Re: building BREXX
On Tue, Feb 18, 2020 at 03:44 PM, rvjansen@... wrote:
one IPL is not enough to get it in working state againThat is weird ... could it be something to do with resident code?(global variables) surviving the IPL? Or worse being shared between CMS users. Both of these I though / assumed was impossible so would be interested in thoughts from anyone ... Anyway, Rene - great progress - I am sure we will crack it! I hope to have a docker image with the new GCCLIB build tomorrow. It will be interesting to see if this helps any of the REXX IO issues. We might need to rebuild BREXX. Adrian |
Re: building BREXX
开云体育Hi Adrian,I checked in the current source, will add some of the VM modules also. I started with the .corig sources and checked them in as.c, and then checked in the current .c modules, so we can track them with git diff. As a result, some of the files are empty now (and are not part of the build procedure - hmm). Btw, I scripted the downloads with s3270 - something else to consider for automation of building and testing. Very probably we will need some extra containers, with the 1.2 sixpack for example, and the Dr. Latz fix, before we can bring it all together. I hope we will find and fix some of the more infuriating aspects of BREXX on VM/370, which is the absolute flakeyness in loading files and getting their names wrong, especially with 8 character filenames; and the fact that sometimes one IPL is not enough to get it in working state again. I hope that the improvements in the gcc library also will help in getting more stability. I’ll leave the build process automation and release process to you then, and will focus on debugging first. I just realized that I always used Rexx to start debug sessions and set breakpoints - with MVS, that is, hmm again. I also started adding issues to work on, mostly for myself and to document potential progress. best regards, 搁别苍é.
|
Re: GCCLIB Advice
开云体育I would think so. Use #CP DISPLAY to display the content of the jump table to seem where the routines are loaded? ? Dave ? From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 16 February 2020 19:03 To: [email protected] Subject: Re: [h390-vm] GCCLIB Advice ? Yes reslib, it seems to pickup externs from the global lib fine. Question is does this pull it all into highmem? Is there a way to see the size of it? I could do a sanity check ... |
Re: GCCLIB Advice
开云体育What are you using to load it? RESLIB? ? Dave ? From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 16 February 2020 18:16 To: [email protected] Subject: Re: [h390-vm] GCCLIB Advice ? The TEXT file is all the TEXT files appended together with COPYFILE. I am amazed this works but anyway! |
Re: GCCLIB Advice
The TEXT file is all the TEXT files appended together with COPYFILE. I am amazed this works but anyway!
After experimenting I think we just need the jump table in the TEXT file, and by having the “global txtlib gcclib” in sysprofile CMS automatically pulls in from the library. It works - the question is, is there anything bad with this - i.e. does everything go into high memory if I do it this way round? Adrian? |
Re: GCCRES (GCCLIB Res Stub) is rather large
开云体育The fixed GCCLIB with the fixed pointer is a huge improvement…
? From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 16 February 2020 18:12 To: [email protected] Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large ? OK - Got my head round it ... and it is working. I think that we should still treat it as beta but it is a massive product, and this version will be a big improvement on the one on the six pack, I think. |
Re: GCCRES (GCCLIB Res Stub) is rather large
OK - Got my head round it ... and it is working. I think that we should still treat it as beta but it is a massive product, and this version will be a big improvement on the one on the six pack, I think.
I have found some test scripts for the STDC library ...? |
Re: GCCRES (GCCLIB Res Stub) is rather large
Especially in the case of a REXX program that calls another REXX program,
the two programs should not end up accessing each others variables. Regards, Peter Coghlan. Date: Sun, 16 Feb 2020 10:07:28 +0000 From: Dave Wade <dave.g4ugm@...> Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large To: [email protected] Yes it makes sense. If REXX calls another program using the shared library then won’t it need this? Dave From: [email protected] <[email protected]> On Behalf Of adriansutherland67 Sent: 16 February 2020 09:59 To: [email protected] Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large Rereading the code I am a bit clearer. Still think gcccrab is overkill (or perhaps underkill and it should become a facility that things like brexx could use). It allows user process specific variables when using a shared libres library. Otherwise all programs using the library would share the same global variable. If that makes any sense. (Presumably brexx having shared variables would be a good thing to allow a program like execio to update rexx variables ... but anyway!) The debugging issue is without printf working I can't be sure if the call to a resident function is not working, or just the gcccrab bit meaning stdout is busted. Oh well ... Work continues |
Re: GCCRES (GCCLIB Res Stub) is rather large
开云体育Yes it makes sense. If REXX calls another program using the shared library then won’t it need this? ? Dave ? From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 16 February 2020 09:59 To: [email protected] Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large ? Rereading the code I am a bit clearer. |
Re: GCCRES (GCCLIB Res Stub) is rather large
Rereading the code I am a bit clearer.
Still think gcccrab is overkill (or perhaps underkill and it should become a facility that things like brexx could use). It allows user process specific variables when using a? shared libres library. Otherwise all programs using the library would share the same global variable. If that makes any sense. (Presumably brexx having shared variables would be a good thing to allow a program like execio to update rexx variables ... but anyway!) The debugging issue is without printf working I can't be sure if the call to a resident function is not working, or just the gcccrab bit meaning stdout is busted. Oh well ... Work continues |
Re: GCCLIB Advice
开云体育I think that the:- ? “global txtlib gcclib” ? Means that when you load something “normally” you get the “normal” “C” library. ? ? Dave ?
? From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 15 February 2020 17:04 To: [email protected] Subject: [h390-vm] GCCLIB Advice ? I am trying to make sure I understand what is going on?
Is that right? GLOBAL TXTLIB GCCLIB RESLIB LOAD GCCLIB (NAME GCCLIB |
Re: GCCRES (GCCLIB Res Stub) is rather large
开云体育Adrian, I think something is wrong with the profiles being used. When I loaded the modified version from Hans (I think its Hans) things worked, but something isn’t and I am travelling so don’t have time to look now. Dave ? From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 15 February 2020 19:35 To: [email protected] Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large ? Thanks Dave - I have tested it (with hello world only). The traditional library works (GCCLIB), the resident one doesn't. |
Re: GCCRES (GCCLIB Res Stub) is rather large
Thanks Dave - I have tested it (with hello world only). The traditional library works (GCCLIB), the resident one doesn't.
Dave - you mentioned that you had it working on your latest version - have you the source that you built, or did you just take it off the binary tape? I will run the test from the binaries on the tape tomorrow. Cheers Adrian |
Re: GCCRES (GCCLIB Res Stub) is rather large
Ok. When I say loaded high I mean loaded with RESLIB. In a modern CMS we have relocatable modules and nucxload which loads this as nucleus extensions. RESLIB does much of this but not all.... Dave On Sat, 15 Feb 2020, 6:32 pm adriansutherland67, <adrian@...> wrote: On Sat, Feb 15, 2020 at 05:57 PM, Dave Wade wrote: |
Re: GCCRES (GCCLIB Res Stub) is rather large
On Sat, Feb 15, 2020 at 05:57 PM, Dave Wade wrote:
REXX to be dynamically loaded into high memory, so it can callBut does gcclib need to be resident to allow rexx to be resident? And is loaded in high memory the same as resident? I am assuming so ... The solution I am looking at seems very complex and brittle. Seems only to be needed for stdin and stdout. And I am not sure it works (I fear incompatible versions of assembler sources). I will light it up and see how it goes.? Personally my reading of all the code is people are only using the traditional library and not the resident one, however by changing the GCC calling prologue it is doing potentially evil. I am not being critical, we are all volunteers, and I am often wrong. I am just trying to report what I see and be transparent! Please don't anyone take offence :-) Anyway I think I will test it. If it works, my bad, I will try harder. If it does not work I will unwind all the weird stuff and make it a baseline traditional library. I hope this will still work for rexx (perhaps it will be too big to go into high mem?) Then I will implement a resident library. Using a c static variable for stdin etc. |
Re: GCCRES (GCCLIB Res Stub) is rather large
开云体育Adrian, As I said to Rene a while ago, the while point of all of this is to allow REXX to be dynamically loaded into high memory, so it can call other programs that run in the user space without getting over written. Usually CMS loads things at 20000 (hex) so if you generate REXX as a normal module then when you call another program you wipe yourself out. I believe that if your program uses OS storage macros, when an OS program terminates CMS re-initializes the storage so its important that REXX does not use any OS macros either. Dave (btw some small CMS programs load at E000, the transient program area, but REXX won’t fit there, an any way if it then called a program that runs there it would still over write its self) ? From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 15 February 2020 17:19 To: [email protected] Subject: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large ? It is disappointingly large relative to the real library - need to improve this (otherwise why bother!) ? ? ? ? ?EXTRN GCCANCHR GETS? ? ?CSECT ? ? ? ? ?USING GETS,R15 ? ? ? ? ?L? ? ?R15,=V(GCCANCHR) get anchor ptr ? ? ? ? ?L? ? ?R15,0(R15)? ? ? ?get the anchor ? ? ? ? ?LA? ? R15,VTGETS(R15) ? ? ? ? ?BR? ? R15? ? ? ? ? ? go there ? ? ? ? ?LTORG ? ? ? ? ?VTABLE ? ? ? ? ?REGEQU ? ? ? ? ?END |
GCCRES (GCCLIB Res Stub) is rather large
It is disappointingly large relative to the real library - need to improve this (otherwise why bother!)
It is full of stub functions like this one ? ? ? ? ?EXTRN GCCANCHR
GETS? ? ?CSECT
? ? ? ? ?USING GETS,R15
? ? ? ? ?L? ? ?R15,=V(GCCANCHR) get anchor ptr
? ? ? ? ?L? ? ?R15,0(R15)? ? ? ?get the anchor
? ? ? ? ?LA? ? R15,VTGETS(R15)
? ? ? ? ?BR? ? R15? ? ? ? ? ? go there
? ? ? ? ?LTORG
? ? ? ? ?VTABLE
? ? ? ? ?REGEQU
? ? ? ? ?END I don't fully understand it yet. The point is that each stub is a seperate file/member. Two questions are: 1.VTABLE is quite large. Is it being duplicated in each member? Hence the large size of the TXTLIB. If I put more than one function / sub in the same ASSEMBLE would it therefore be smaller? 2. When linking does it only pull in the members used? Or does it pull in everything from the library? Thanks again! |
GCCLIB Advice
I am trying to make sure I understand what is going on?
The MKGCCLIB EXEC makes 3 files
However, in the SYSPROG EXEC I have GLOBAL TXTLIB GCCLIB
RESLIB LOAD GCCLIB (NAME GCCLIB Now why are we doing the GLOBAL TXTLIB? There is no member called GCCLIB of course. So is it just a harmless error, or am I missing something in my mental image of what is going on? Thanks!!? |