Re: TXTLIB and Stack Question
Its called the C calling convention (so you can google it)
I think GCCMVS uses either R13 or R14 for the stack pointer. So basically the program defines a bunch of space for its stack at the beginning (see the end of?
R13 or 14 (sorry I don't know which) points to it. When a function is called the function moves the register down enough to make space for its local variables. When the function is done it can put the stack pointer back. The return address, return value and arguments are also put / read from the stack.
Hope that makes some sense!
?
|
Re: TXTLIB and Stack Question
On 25 Feb 2020, at 18:48, adriansutherland67 < adrian@...> wrote:
As you know C uses a stack for local variables - so reentrancy is not an issue. But for global variables (static, extern), it just adds then to the code flat - which is why you had to and we have to code in such a way as to avoid globals - in this case we will have to use getmain, and use a stack to track which set of "global variables" should be exposed.?
As the mainframe did not have a stack until fairly late, I am curious as to how that is handled in GCC on VM/370. Simulating a stack without an instruction set to work upon it seems complex, if not to say, error prone.
If I try a very simple program with two local variables to main, x and y, both integers and I assign 7 and 8 to them:
int main(int argc, char ?*argv[]){ int i,j; ? ? ? ? ? ? ? ? ? ? ? ? ? i = 7; ? ? ? ? ? ? ? ? ? ? ? ? ? ? j = 8; ? ? ? ? ? ? ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
This is what it generates, I don’t see a stack.?
00001D 00 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00001E 90EC D00C ? ? ?0000C ? ? ? ? ?81+ ? ? ? ? STM ? 14,12,12(13) ? ? 000022 18CF ? ? ? ? ? ? ? ? ? ? ? ? ?82+ ? ? ? ? LR ? ?12,15 ? ? ? ? ?? 000024 58F0 D04C ? ? ?0004C ? ? ? ? ?83+ ? ? ? ? L ? ? 15,76(,13) ? ? ? 000028 50D0 F004 ? ? ?00004 ? ? ? ? ?84+ ? ? ? ? ST ? ?13,4(,15) ? ? ?? 00002C 50F0 D008 ? ? ?00008 ? ? ? ? ?85+ ? ? ? ? ST ? ?15,8(,13) ? ? ?? 000030 18DF ? ? ? ? ? ? ? ? ? ? ? ? ?86+ ? ? ? ? LR ? ?13,15 ? ? ? ? ?? 000032 41F0 F060 ? ? ?00060 ? ? ? ? ?87+ ? ? ? ? LA ? ?15,96(,15) ? ? ? 000036 50FD 004C ? ? ?0004C ? ? ? ? ?88+ ? ? ? ? ST ? ?15,76(13) ? ? ?? 00003A 47F0 C02C ? ? ?00040 ? ? ? ? ?89 ? ? ? ? ?B ? ? FEN0 ? ? ? ? ? ? 000040 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 90 ? ? ? ? ?LTORG ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00040 ? ?91 FEN0 ? ? EQU ? * ? ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?92 ? ? ? ? ?DROP ?12 ? ? ? ? ? ? ? 000040 05C0 ? ? ? ? ? ? ? ? ? ? ? ? ?93 ? ? ? ? ?BALR ?12,0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00042 ? ?94 ? ? ? ? ?USING *,12 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00042 ? ?95 PG0 ? ? ?EQU ? * ? ? ? ? ? ? ?? 000042 18B1 ? ? ? ? ? ? ? ? ? ? ? ? ?96 ? ? ? ? ?LR ? ?11,1 ? ? ? ? ? ? 000044 58A0 C026 ? ? ?00068 ? ? ? ? ?97 ? ? ? ? ?L ? ? 10,=A(PGT0) ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?98 * Function main code ? ? ? ? ?? 000048 D203 D058 C02A 00058 0006C ? ?99 ? ? ? ? ?MVC ? 88(4,13),=F'7' ? 00004E D203 D05C C02E 0005C 00070 ? 100 ? ? ? ? ?MVC ? 92(4,13),=F'8' ? 000054 1F22 ? ? ? ? ? ? ? ? ? ? ? ? 101 ? ? ? ? ?SLR ? 2,2 ? ? ? ? ? ?? 000056 18F2 ? ? ? ? ? ? ? ? ? ? ? ? 102 ? ? ? ? ?LR ? ?15,2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
so it stores the two values in?88(4,13) and 92(4,13) which I don’t see getmained anywhere. The LTORG a bit further down shows that the F’7’ and F’8’ are a part of the literal pool, so in the .text and load module. So each mvc moves 4 bytes (4 to offset 88 and 92 from the content of register 4. What is in there I cannot see clearly, it is not something we getmained?
搁别苍é.
|
Re: TXTLIB and Stack Question
On 2/25/20 8:06 AM, gdblodgett wrote:
On 2/25/20 10:29 AM,
adriansutherland67 wrote:
On Tue, Feb 25, 2020 at 02:27 PM, adriansutherland67 wrote:
ARGVARGS
No - it was ARGVARGS - (too similar names - I hate it).
Anyway bug fixed :-)
So my general policy will be to ignore this file as too hard -
but maybe one day replace the parameter bits with some nice
friendly C - LOL!
??? I agree that Assembler is harder than most languages, but
some would say that "it separates the men from the boys".?
I guess that makes me a man since about 1982. What does knowing
FORTRAN IV since 1977 do for my score?
As far a C being friendly, I guess that is in the eye of the
beholder.?
"C combines the power of assembler with the portability of
assembler.'' - Anonymous
BASIC and COBOL in my opinion are "friendlier".?
If you want unfriendly, try passing a character variable from
PL/I (F) to Assembler.? (They cleaned it up some in the PL/I
Optimizer).
OTOH, PL/I has block constructs and words for labels.? FORTRAN IV
& classic BASIC having neither is the pits.? (You too can try
to remember what label 502 stands for ...)
I've seen C code that makes me want an assembler program any
day because the original developer was trying to be slick and
fancy.
"Clever" is the bane of good coders everywhere.
Flon's Law:? There is not now, and never will be, a language in
which it is the least bit difficult to write bad programs.
-ahd-
--
Drew Derbyshire
"Manners are a sensitive awareness of the feelings of others. If you
have that awareness, you have good manners, no matter what fork you
use." -- Emily Post
|
Re: TXTLIB and Stack Question
On Tue, Feb 25, 2020 at 05:02 PM, rvjansen@... wrote:
(Would just initializing everything solve that scenario?).
Yes - and in C I believe the standard is that the compiler initializes variables for you - this case it was some assembler code (which I consider a dark art!) As you know C uses a stack for local variables - so reentrancy is not an issue. But for global variables (static, extern), it just adds then to the code flat - which is why you had to and we have to code in such a way as to avoid globals - in this case we will have to use getmain, and use a stack to track which set of "global variables" should be exposed. When we enter main() we push a new struct, when we leave we pop one off (I am sure error conditions causing a program exit where we have forgotten to "pop" will cause us lots of insane bugs {shrug}). Modern linkers are different - they take care of all this without programmers noticing. If two programs link to a shared library dynamically all the globals are initialised sanly and transparently, and remember with C++ this is not trivial! A
|
Re: TXTLIB and Stack Question
On 25 Feb 2020, at 17:56, adriansutherland67 < adrian@...> wrote:
Its the linker that is the issue.
I don’t understand. As I remember, we needed to make sure that for reentrant code, we coded it in a way that there were no storage areas that were not getmained and initialized by our code. You could ask the linkage editor to ‘RENT’ but it would only check, not make it reentrant for you. Now I understand there is no multitasking in CMS (in VM/370, that is) but it would be great if every exec would not need to take care if a previous user (yourself in most cases) did not leave things in fields. (Would just initializing everything solve that scenario?).
搁别苍é.
|
Re: TXTLIB and Stack Question
On Tue, Feb 25, 2020 at 04:39 PM, rvjansen@... wrote:
compiler that generates reentrant code
Its the linker that is the issue. Anyway "all" we have to do is pull out all the globals that BREXX use and put them in a struct. Each call (recursive/reentrant) to BREXX instanciates a struct object, organised as a stack - job's done :-) ha! It will never be multithreaded - but that is irrelevant for CMS. This defect was just one of those weird ones ... I will be interested if you find any more funny IO scenarios - it would be good to just get stability / confidence. In fact, I am going to add a reentrant checker to block these calls so as to avoid confusion until we get it working properly. Adrian
|
Re: TXTLIB and Stack Question
I will need to read the old CMS books, but for MVS you’ll need the list-versions of the macro’s (MF=L) and map a getmained chunk of memory. Mike’s original Rex interpreter code was reentrant assembler and had to deal with paging drums etc.
I am glad you found where the problem is, because its non-predictabilty nearly drove me crazy.
I wonder if, short of a compiler that generates reentrant code, the brexx interpreter cannot just be reloaded after external calls. PC DOS batch had a stub that reloaded the command processor if it was overwritten, for example; that only needs to be done when non-statically linked code overlays Brexx, like external commands. The part that implements ADDRESS maybe can do that.
best regards,
搁别苍é.
toggle quoted message
Show quoted text
My guess would be local as I don't see anything in the code to
indicate that would be re-entrant or designed to be loaded
resident, but I will defer to the current maintainers.? A shared
stack is usually created via a "GETMAIN" type call with uses
memory outside of program storage with its address stored in a
Control Block type construct. Gary
On 2/25/20 10:53 AM, adriansutherland67
wrote:
On Tue, Feb 25, 2020 at 12:09 PM, gdblodgett wrote:
The DS in the MAINSTK statement means Define Storage.?
The 32000F states that variable 32000 "F"s in size.? With "F"
meaning a full word (4 bytes) aligned on a full word boundary.?
So it's 32000 x 4 = 128000 bytes long, aligned on a full word
boundary.?
So does this mean that the stack is local to each instance of the
program? I.e. if 2 programs link with GCCLIB will they have the
same stack, or not??
Presumably if the stack was defined as part of the GCCLIB loaded
resident then they would indeed share the same stack -
disastrously!
Thanks for any hints!
|
Re: TXTLIB and Stack Question
On Tue, Feb 25, 2020 at 04:20 PM, gdblodgett wrote:
I will defer to the current maintainers
I fear that is me! Local is good - its what I had assumed.? Last question for a bit (promise) - does CMS generally load programs to the same address and not clear up memory between program launches? I just want to get to the bottom of how one run of a program leaves stuff behind that interferes with the next program.
|
Re: TXTLIB and Stack Question
My guess would be local as I don't see anything in the code to
indicate that would be re-entrant or designed to be loaded
resident, but I will defer to the current maintainers.? A shared
stack is usually created via a "GETMAIN" type call with uses
memory outside of program storage with its address stored in a
Control Block type construct.
Gary
On 2/25/20 10:53 AM, adriansutherland67
wrote:
toggle quoted message
Show quoted text
On Tue, Feb 25, 2020 at 12:09 PM, gdblodgett wrote:
The DS in the MAINSTK statement means Define Storage.?
The 32000F states that variable 32000 "F"s in size.? With "F"
meaning a full word (4 bytes) aligned on a full word boundary.?
So it's 32000 x 4 = 128000 bytes long, aligned on a full word
boundary.?
So does this mean that the stack is local to each instance of the
program? I.e. if 2 programs link with GCCLIB will they have the
same stack, or not??
Presumably if the stack was defined as part of the GCCLIB loaded
resident then they would indeed share the same stack -
disastrously!
Thanks for any hints!
|
Re: TXTLIB and Stack Question
On 2/25/20 10:29 AM, adriansutherland67
wrote:
On Tue, Feb 25, 2020 at 02:27 PM, adriansutherland67 wrote:
ARGVARGS
No - it was ARGVARGS - (too similar names - I hate it).
Anyway bug fixed :-)
So my general policy will be to ignore this file as too hard - but
maybe one day replace the parameter bits with some nice friendly C
- LOL!
??? I agree that Assembler is harder than most languages, but
some would say that "it separates the men from the boys".? As far
a C being friendly, I guess that is in the eye of the beholder.?
BASIC and COBOL in my opinion are "friendlier".? I've seen C code
that makes me want an assembler program any day because the
original developer was trying to be slick and fancy.
My SOP is to use the language that best fits the purpose.? If you
think assembler is hard, try writing machine code patches.? Loads
of fun...
Gary
|
Re: TXTLIB and Stack Question
On Tue, Feb 25, 2020 at 12:09 PM, gdblodgett wrote:
The DS in the MAINSTK statement means Define Storage.? The 32000F states that variable 32000 "F"s in size.? With "F" meaning a full word (4 bytes) aligned on a full word boundary.? So it's 32000 x 4 = 128000 bytes long, aligned on a full word boundary.?
So does this mean that the stack is local to each instance of the program? I.e. if 2 programs link with GCCLIB will they have the same stack, or not?? Presumably if the stack was defined as part of the GCCLIB loaded resident then they would indeed share the same stack - disastrously! Thanks for any hints!
|
Re: TXTLIB and Stack Question
On Tue, Feb 25, 2020 at 02:27 PM, adriansutherland67 wrote:
ARGVARGS
No - it was ARGVARGS - (too similar names - I hate it). Anyway bug fixed :-) So my general policy will be to ignore this file as too hard - but maybe one day replace the parameter bits with some nice friendly C - LOL!
|
Re: TXTLIB and Stack Question
On Tue, Feb 25, 2020 at 02:16 PM, gdblodgett wrote:
The 257 byte length of the ARGVARGS field will indeed hold 32 arguments (8x32=256) plus 1 byte for a fence/termination character.
Thanks Gary hope you had a good coffee! I am trying the fix now - it is?ARGSTRNG that I need to clear (dyslexia). You are right that ARGVARS is big enough - but ARGSTRNG?needs to hold spaces ... and the program name - and with eplist could be longer?? Anyway, a theoretical problem, I will raise an issue for another day!
|
Re: TXTLIB and Stack Question
Hi Adrian,
OK, I've had enough coffee and am awake now.? LOL
Yes, the MVI & MVC combination is pretty much the norm for
clearing/initializing memory.? I've seen other ways, but I'll not
cloud the issue.? Clearing/initializing that field is a good idea.
With C, the argc/argv combination gives you the actual value(s)
from the command line.? In IBM assembler the PLIST gives you the
address of the location of each of the 8 byte values.?
An example in the program is on line 55.? In the comment area
"RESLIB LIST GCCLIB ( NOTYPE" would be typed on the command line.?
Line 290-295 shows how it will appear after being parsed.? The
PLIST will contain the address of each portion of the command line
plus and 8 byte "fence"/termination field of all x'FF' (high
values).
Eight (8) is the magic number because Command names, file names,
file types and the like in CMS are all 8 characters or less.
The 257 byte length of the ARGVARGS field will indeed hold 32
arguments (8x32=256) plus 1 byte for a fence/termination
character.
Gary
On 2/25/20 6:57 AM, adriansutherland67
wrote:
toggle quoted message
Show quoted text
OK - So I understand the issue now with PLIST, basically I would
need to add
MVI? ?0(R3),C' '
after line 253. This makes sure that the proper end of the token
is found even is some preexisting junk is there in the target
ARGVARGS.
But I have no chance of seeing if the same
problem exists in EPLIST let alone fixing it (for a start I could
not test it!).
Therefore the safest thing to do is instead clear this
ARGVARGS DS CL257
down to zeros (or spaces?) first. The trouble is my S/370 is crap
(nonexistent!), is this the most efficient/elegant way?
MVI?
ARGVARGS,X'0'? ? ? ? ? ? ? ? ?* Zero start
MVC?
ARGVARGS+1(256),ARGVARGS? ? ? * Propagate to the rest?
Anyway I will see it it works!
|
Re: TXTLIB and Stack Question
Hi Adrian,
Assembler can be cryptic at times but so can C.
The DS in the MAINSTK statement means Define Storage.? The 32000F states that variable 32000 "F"s in size.? With "F" meaning a full word (4 bytes) aligned on a full word boundary.? So it's 32000 x 4 = 128000 bytes long, aligned on a full word boundary.?
The meaning for "ARGVARGS DS? ? CL257" is again, define storage, this time though is a different notation. The "C" means character (1 byte), the "L" means length. So, it is 257 bytes long with no alignment enforced.?
I've just crawled out of bed, but I will try and take a peek at it after I get some coffee.
Gary?
Sent from my T-Mobile 4G LTE Device
toggle quoted message
Show quoted text
-------- Original message -------- From: adriansutherland67 <adrian@...> Date: 2/25/20 4:50 AM (GMT-05:00) Subject: [h390-vm] TXTLIB and Stack Question
Hello I am chasing down a bug in CMSLIB whereby (TBC) the last argument to main() is not properly null terminated if it is 8 chars long and a previous C command had a longer program name (note that the program name is arg 0). I note that the bit that does this is all assembler :-( Anyway, I unexpectedly found this was true between resident (DMXREX) and nonresident versions (BREXX) - one interferes with the other.?? Can anyone help with the following questions - I appreciate they will be in a doco but I also know that some of you will just know! I also appreciate that CMS is a simple single user / program system - multi-process was not the order of the day ... 1/ If two programs use the same TXTLIB (e.g. but I guess not only, if one is resident and the other isn't) is the TXTLIB loaded in memory once only - the two programs share the TXTLIB and any global variables. Is this right? 2/ In the C startup library I see
* ---------------------------------------------------------------------
* Here begins the GCC stack:? local variables of the GCC routines.
* ---------------------------------------------------------------------
MAINSTK? DS? ? 32000F
a/ Is this telling me that the stack starts at 32000 hex (about 200k) and therefore the stack grows upwards, or is it hex 32000F (about 3mb) which seems a weird address ... b/ This means that all C programs stacks start at the same address and will inevitably trash each others stacks? Has anyone any suggestions about how CMS Assembler programs get round this - I remember something about? CMS subset? Does that have different standard addresses? And what about programs loaded high? 3/ Similarly
ARGVARGS DS? ? CL257? ? ? ? ? arguments to main program
Tells me that this buffer for main() arguments is in a non-reentrant global variable - right? It is also too short for 32 args mentioned elsewhere in the code, but anyway! And The bug ...The file is here? And line 215 seems fine (terminating) - but it does not check that the arg is 8 chars or fewer. From testing the symptom, it is about the program name being shorter (from the last run) and somehow the calculation of the start of the parameters is out, and it is picking up a character from the previous run at the end of the params. So can anyone help with line 150? I think this should point to char 8 (or 9?) from the START of the program name, is it pointing to the end of the trimmed / stripped program name instead?? Does anyone have the format of the EPLIST or whatever? And - I wish this bit was written in C!!!! I am quite scared about changing it :-) Adrian
|
Re: TXTLIB and Stack Question
OK - So I understand the issue now with PLIST, basically I would need to add
MVI? ?0(R3),C' '
after line 253. This makes sure that the proper end of the token is found even is some preexisting junk is there in the target ARGVARGS. But I have no chance of seeing if the same problem exists in EPLIST let alone fixing it (for a start I could not test it!). Therefore the safest thing to do is instead clear this
ARGVARGS DS CL257
down to zeros (or spaces?) first. The trouble is my S/370 is crap (nonexistent!), is this the most efficient/elegant way?
MVI? ARGVARGS,X'0'? ? ? ? ? ? ? ? ?* Zero start
MVC? ARGVARGS+1(256),ARGVARGS? ? ? * Propagate to the rest?
Anyway I will see it it works!
|
TXTLIB and Stack Question
Hello I am chasing down a bug in CMSLIB whereby (TBC) the last argument to main() is not properly null terminated if it is 8 chars long and a previous C command had a longer program name (note that the program name is arg 0). I note that the bit that does this is all assembler :-( Anyway, I unexpectedly found this was true between resident (DMXREX) and nonresident versions (BREXX) - one interferes with the other.?? Can anyone help with the following questions - I appreciate they will be in a doco but I also know that some of you will just know! I also appreciate that CMS is a simple single user / program system - multi-process was not the order of the day ... 1/ If two programs use the same TXTLIB (e.g. but I guess not only, if one is resident and the other isn't) is the TXTLIB loaded in memory once only - the two programs share the TXTLIB and any global variables. Is this right? 2/ In the C startup library I see
* ---------------------------------------------------------------------
* Here begins the GCC stack:? local variables of the GCC routines.
* ---------------------------------------------------------------------
MAINSTK? DS? ? 32000F
a/ Is this telling me that the stack starts at 32000 hex (about 200k) and therefore the stack grows upwards, or is it hex 32000F (about 3mb) which seems a weird address ... b/ This means that all C programs stacks start at the same address and will inevitably trash each others stacks? Has anyone any suggestions about how CMS Assembler programs get round this - I remember something about? CMS subset? Does that have different standard addresses? And what about programs loaded high? 3/ Similarly
ARGVARGS DS? ? CL257? ? ? ? ? arguments to main program
Tells me that this buffer for main() arguments is in a non-reentrant global variable - right? It is also too short for 32 args mentioned elsewhere in the code, but anyway! And The bug ...The file is here? And line 215 seems fine (terminating) - but it does not check that the arg is 8 chars or fewer. From testing the symptom, it is about the program name being shorter (from the last run) and somehow the calculation of the start of the parameters is out, and it is picking up a character from the previous run at the end of the params. So can anyone help with line 150? I think this should point to char 8 (or 9?) from the START of the program name, is it pointing to the end of the trimmed / stripped program name instead?? Does anyone have the format of the EPLIST or whatever? And - I wish this bit was written in C!!!! I am quite scared about changing it :-) Adrian
|
Re: CTCE on the same host with unique ports
Please note that my? of the? is available for anyone who wishes to beta test my CTCE v2 corrections and improvements (as well as some older changes). The code is not finalized yet, some problems are known to exist, but as a successful CTCE connection was made yesterday (a VTAM non-MPC CTCA link to a? Hercules system), I'd appreciate testing feedback. The new CTCE support for the CTC DEBUG ON <devnum> command may be helpful.
When this spinhawk CTCE v2 work has been sufficiently tested, I will make a pull request for it, but cannot guarantee that these will be actually carried out.?
Feedback welcome !
Cheers,
Peter?
|
Re: CTCE on the same host with unique ports
On 2/24/20 12:44 AM, Peter Jansen via Groups.Io wrote: Drew, the upcoming backport of my CTCE v2 corrections and improvements will have an improved output from the DEVLIST <devnum> command which I thus hope will address this. The existing command CTC DEBUG … will then also support CTCE devices to assist debugging this even better. If you point me at your next CTCE Spinhawk version when it's public (github?), I'll beta test.? :-) -- Drew Derbyshire "A hobbit will get you through times of no bagels better than bagels will get you through times of no hobbit." -- The Grey-eyed Elf
|
Re: CTCE on the same host with unique ports
Drew, the upcoming backport of my CTCE v2 corrections and improvements will have an improved output from the DEVLIST <devnum> command which I thus hope will address this. The existing command CTC DEBUG … will then also support CTCE devices to assist debugging this even better.
Cheers,
Peter
|
Peter Jansen