Discussion:
z/Linux 32-bit modules
(too old to reply)
Harold Grovesteen h.grovsteen@tx.rr.com [hercules-390]
2018-05-21 20:09:38 UTC
Permalink
Hi. I'm not sure where the best place to ask
this is, as it is not Hercules-specific.
When 32-bit modules are created on z/Linux
using "gcc -m32" or whatever, is the resultant
module run as AM31 or AM64?
Thanks. Paul.
 
On a 64-bit system running in z/Architecture mode, they are run under
Linux in AM31.  This has implications about where they are placed
within virtual storage.

The 32-bit ELF file format, assumes an ESA/390 environment.  For ELF
modules within a process, this means AM31.

Harold Grovesteen
kerravon86@yahoo.com.au [hercules-390]
2018-05-21 23:41:05 UTC
Permalink
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
On a 64-bit system running in z/Architecture mode, they are run under
Linux in AM31. This has implications about where they are placed
within virtual storage.
The 32-bit ELF file format, assumes an ESA/390 environment. For ELF
modules within a process, this means AM31.
Hi Harold. Thanks for that. What happen if
the 32-bit module is loaded within RM31
space, but run as AM64?

Thanks. Paul.
Harold Grovesteen h.grovsteen@tx.rr.com [hercules-390]
2018-05-22 14:55:21 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
On a 64-bit system running in z/Architecture mode, they are run under
Linux in AM31.  This has implications about where they are placed
within virtual storage.
The 32-bit ELF file format, assumes an ESA/390 environment.  For
ELF
modules within a process, this means AM31.
Hi Harold. Thanks for that. What happen if
the 32-bit module is loaded within RM31
space, but run as AM64?
Thanks. Paul.
 
I am not an expert on how Linux processes are set up.  But, my
understanding is that the initial ELF used to launch the process will
dictate the modules that may be used by the process.  In other words,
there are no mixing of modules in a process.  Either they are all 31-
bit or all 64-bit.

To mix them would require address mode changes between them when one
module calls another.  The ELF ABI document dictates how these things
occur has no provision for understanding when such changes are needed
to occur.  The ELF ABI dictates how C programs create modules.  So,
obviously assembler code can manipulate AMODE, but when attempted with
a bunch of C modules, the results are likely unpredictable and likely
disastrous. 

At the hardware level, when the kernel dispatches a process, it must
load a PSW with an AMODE setting.  I do not believe the AMODE changes
once the process is initially dispatched.

Anyone with better information, please share it.

Harold
Harold Grovesteen h.grovsteen@tx.rr.com [hercules-390]
2018-05-22 15:03:55 UTC
Permalink
On Tue, 2018-05-22 at 09:55 -0500, Harold Grovesteen
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
On a 64-bit system running in z/Architecture mode, they are run under
Linux in AM31.  This has implications about where they are placed
within virtual storage.
The 32-bit ELF file format, assumes an ESA/390 environment.  For
ELF
modules within a process, this means AM31.
Hi Harold. Thanks for that. What happen if
the 32-bit module is loaded within RM31
space, but run as AM64?
Thanks. Paul.
 
I am not an expert on how Linux processes are set up.  But, my
understanding is that the initial ELF used to launch the process will
dictate the modules that may be used by the process.  In other words,
there are no mixing of modules in a process.  Either they are all 31-
bit or all 64-bit.
To mix them would require address mode changes between them when one
module calls another.  The ELF ABI document dictates how these things
occur has no provision for understanding when such changes are needed
to occur.  The ELF ABI dictates how C programs create modules.  So,
obviously assembler code can manipulate AMODE, but when attempted with
a bunch of C modules, the results are likely unpredictable and likely
disastrous. 
At the hardware level, when the kernel dispatches a process, it must
load a PSW with an AMODE setting.  I do not believe the AMODE changes
once the process is initially dispatched.
Anyone with better information, please share it.
Harold
The response from Martin Schwidefsky to your question on the Linux
mailing list is essentially the same as mine, but described a bit
differently.

Harold
Tony Harminc tharminc@gmail.com [hercules-390]
2018-05-24 21:42:49 UTC
Permalink
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
At the hardware level, when the kernel dispatches a process, it must
load a PSW with an AMODE setting. I do not believe the AMODE changes
once the process is initially dispatched.
Keeping in mind, of course, that any program can change its addressing
mode at any time without the kernel being able to do anything about
it. In other words LPSW does not "set" the AMODE for the process for
all time - it's not like Set File Mask in a channel program or
something. Maybe the kernel won't be happy if the code does a SAM64
right away and then is interrupted, but maybe it doesn't care. I have
no idea, but obviously the kernel can't just trust application
programs to not do this.

Tony H.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2018-05-24 21:51:27 UTC
Permalink
Post by Tony Harminc ***@gmail.com [hercules-390]
Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
At the hardware level, when the kernel dispatches a process, it must
load a PSW with an AMODE setting. I do not believe the AMODE changes
once the process is initially dispatched.
Keeping in mind, of course, that any program can change its addressing
mode at any time without the kernel being able to do anything about
it. In other words LPSW does not "set" the AMODE for the process for
all time - it's not like Set File Mask in a channel program or
something. Maybe the kernel won't be happy if the code does a SAM64
right away and then is interrupted, but maybe it doesn't care. I have
no idea, but obviously the kernel can't just trust application
programs to not do this.
If a ELF program which is marked as 31 bit (actually 32 bit - Byte 4 of
the ELF header being set to ELFCLASS32 - 1)  is loaded through exec[ve]
, and it issues a SAM64 (which is a problem state instruction - so not
under Kernel control) or attempts to use the whole portions of the 64
bit registers - I'm going to say the results are unpredictable if it
uses any of the bits 0-31 of the 64 bits registers (Most possibly bits
0-31 might not be preserved if the process/thread yields).

The answer is just : Don't do that !

--Ivan



[Non-text portions of this message have been removed]
kerravon86@yahoo.com.au [hercules-390]
2018-05-21 23:51:18 UTC
Permalink
Because other systems like x64 have a special
environment that in effect gives the equivalent
of AMODE 32.
Detail there if I may. By and large x64 doesn't need an explicit
emulation environment to support x86 (i386) 32-bit code, but it might
need system libraries which aren't installed as standard.
Not sure if we're talking cross-purposes here.

32-bit modules that e.g. use "push eax" do not
work in 64-bit mode, as that becomes "push rax".
In addition a negative index wraps at 32 bits.

You can see this here:

https://en.wikipedia.org/wiki/X86-64#Operating_modes

There is a difference between "64-bit mode"
and "compatibility mode".

z/Arch is in an interesting position where 32-bit
code can actually execute in the same mode
(ie 64-bit mode) as 64-bit programs. So long as:

1. The high 32 bits of registers are zero.
2. Negative indexes are not used.

If this is done, 32-bit programs should have
access to a full 4 GiB virtual address space,
instead of being restricted to 2 GiB.

I wish to get some version of z/Linux to start
using a full 4 GiB (if it isn't already) address
space, to provide prior art to getting the same
thing done in z/OS.

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2018-05-22 12:10:26 UTC
Permalink
"z/Arch is in an interesting position where 32-bit
code can actually execute in the same mode
(ie 64-bit mode) as 64-bit programs."

Can you point to the flags for AMODE and RMODE in a Linux ELF?

Joe
Post by ***@yahoo.com.au [hercules-390]
Because other systems like x64 have a special
environment that in effect gives the equivalent
of AMODE 32.
Detail there if I may. By and large x64 doesn't need an explicit
emulation environment to support x86 (i386) 32-bit code, but it might
need system libraries which aren't installed as standard.
Not sure if we're talking cross-purposes here.
32-bit modules that e.g. use "push eax" do not
work in 64-bit mode, as that becomes "push rax".
In addition a negative index wraps at 32 bits.
https://en.wikipedia.org/wiki/X86-64#Operating_modes
There is a difference between "64-bit mode"
and "compatibility mode".
z/Arch is in an interesting position where 32-bit
code can actually execute in the same mode
1. The high 32 bits of registers are zero.
2. Negative indexes are not used.
If this is done, 32-bit programs should have
access to a full 4 GiB virtual address space,
instead of being restricted to 2 GiB.
I wish to get some version of z/Linux to start
using a full 4 GiB (if it isn't already) address
space, to provide prior art to getting the same
thing done in z/OS.
BFN. Paul.
Harold Grovesteen h.grovsteen@tx.rr.com [hercules-390]
2018-05-22 14:59:45 UTC
Permalink
They do not exist.  32-bit vs. 64-bit in the ELF really means 32-bit
registers vs. 64-bit registers.  The fundamental implication is the
implied size of pointers (or addresses).

Harold Grovesteen
Post by Joe Monk ***@gmail.com [hercules-390]
"z/Arch is in an interesting position where 32-bit
code can actually execute in the same mode
(ie 64-bit mode) as 64-bit programs."
Can you point to the flags for AMODE and RMODE in a Linux ELF?
Joe
Because other systems like x64 have a special
environment that in effect gives the equivalent
of AMODE 32.
Detail there if I may. By and large x64 doesn't need an explicit 
emulation environment to support x86 (i386) 32-bit code, but it
might 
need system libraries which aren't installed as standard.
Not sure if we're talking cross-purposes here.
32-bit modules that e.g. use "push eax" do not
work in 64-bit mode, as that becomes "push rax".
In addition a negative index wraps at 32 bits.
https://en.wikipedia.org/wiki/X86-64#Operating_modes
There is a difference between "64-bit mode"
and "compatibility mode".
z/Arch is in an interesting position where 32-bit
code can actually execute in the same mode
1. The high 32 bits of registers are zero.
2. Negative indexes are not used.
If this is done, 32-bit programs should have
access to a full 4 GiB virtual address space,
instead of being restricted to 2 GiB.
I wish to get some version of z/Linux to start
using a full 4 GiB (if it isn't already) address
space, to provide prior art to getting the same
thing done in z/OS.
BFN. Paul.
Tony Harminc tharminc@gmail.com [hercules-390]
2018-05-24 21:36:00 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
z/Arch is in an interesting position where 32-bit
code can actually execute in the same mode
(ie 64-bit mode) as 64-bit programs.
I'm not sure there is anything meaningful to the term "32-bit code" in
the zArch context. Surely it is just 64-bit code that avoids using a
few features. Well, sure, you can apply any labels you like to code,
but is "32-bit" any more valid than "structured" or "recursive" or
"doesn't use the new z14 instructions"?
Post by ***@yahoo.com.au [hercules-390]
1. The high 32 bits of registers are zero.
2. Negative indexes are not used.
Are you quite sure those are the only restrictions?
Post by ***@yahoo.com.au [hercules-390]
If this is done, 32-bit programs should have
access to a full 4 GiB virtual address space,
instead of being restricted to 2 GiB.
So a BXLE loop will work fine...?
Post by ***@yahoo.com.au [hercules-390]
I wish to get some version of z/Linux to start
using a full 4 GiB (if it isn't already) address
space, to provide prior art to getting the same
thing done in z/OS.
Who, imaginably, would do this for z/OS? IBM has certainly made their
feelings clear. And they are even more certainly not going to copy
some code that you put in the PD into z/OS.

Tony H.
kerravon86@yahoo.com.au [hercules-390]
2018-05-25 03:29:58 UTC
Permalink
Post by Tony Harminc ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
z/Arch is in an interesting position where 32-bit
code can actually execute in the same mode
(ie 64-bit mode) as 64-bit programs.
I'm not sure there is anything meaningful to the term "32-bit code" in
the zArch context. Surely it is just 64-bit code that avoids using a
few features. Well, sure, you can apply any labels you like to code,
but is "32-bit" any more valid than "structured" or "recursive" or
"doesn't use the new z14 instructions"?
Excellent question, and what keeps me up at night
trying to get to grips with the world of computers.

I used to think that if something disturbed the
high 32 bits of registers then it was a 64-bit
program that required a 64-bit save area.
So even a program running AM31 that used
64-bit longs would be considered 64-bit.

That's still the case, but not the criteria for
marking a module as ELF32.

There are two independent things that would
need a module flagged as 32, to let the OS
know it needs to handle differently.

One is if code pointers are 32-bit, so someone
has coded like:

SGR Rx,Rx
L Rx=V(MYFUNC)

Or perhaps the SGR is not there at all, and the
program has assumed that the high 32 bits are
0, or doesn't even know that they exist.

This more-or-less necessitates that the module
itself needs to be loaded in RM32 space.

But even if code pointers were 64-bit, the data
pointers may still be 32 bits, and a module
loaded above 4 GiB would still need malloc()
to return addresses below 4 GiB. So another
reason why the module would need to be
marked "32".

It is possibly ideal that the figure "32" should
be split into 32C and 32D as independent
flags. In practice I would say that 32 implies
both C and D, which is what people would
normally do by compiling with gcc -m32 or
whatever.
Post by Tony Harminc ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
1. The high 32 bits of registers are zero.
2. Negative indexes are not used.
Are you quite sure those are the only restrictions?
No. But my small test program works fine as AM64.
GCC doesn't work fine as AM64 because of the
negative index use, but it does run fine as AM32.
Post by Tony Harminc ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
If this is done, 32-bit programs should have
access to a full 4 GiB virtual address space,
instead of being restricted to 2 GiB.
So a BXLE loop will work fine...?
Gerhard uses BXLE in MVS380MN, and I have
confirmed that when that is run as AM64, it still
seems to work fine.
Post by Tony Harminc ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
I wish to get some version of z/Linux to start
using a full 4 GiB (if it isn't already) address
space, to provide prior art to getting the same
thing done in z/OS.
Who, imaginably, would do this for z/OS? IBM has certainly made their
feelings clear.
I'm holding out for an important customer saying
"hey, z/Linux gives 32-bit applications the full
4 GiB address space, why can't we have the
same in z/OS".
Post by Tony Harminc ***@gmail.com [hercules-390]
And they are even more certainly not going to copy
some code that you put in the PD into z/OS.
I don't believe I have any PD code that will
help IBM developers. The most I would be
able to do one day is demonstrate 4 GiB
addressing on MVS/380 or PDOS/380 to
prove what is technically possible.

BFN. Paul.

kerravon86@yahoo.com.au [hercules-390]
2018-05-23 07:01:08 UTC
Permalink
Thanks George.


I was able to post my query there and the
conversation can be viewed here:


https://www.mail-archive.com/linux-***@vm.marist.edu/ https://www.mail-archive.com/linux-***@vm.marist.edu/


BFN. Paul.






---In hercules-***@yahoogroups.com, <***@...> wrote :

LINUX-***@...


Sent from my MetroPCS 4G LTE Android device
The linux kernel is 64-bit ... so why wouldn't it be
run just as any other 32-bit app would be run on
a 64-bit linux system?
Because other systems like x64 have a special
environment that in effect gives the equivalent
of AMODE 32. Since z/Arch doesn't have that,
it is necessary to switch to either AM31 or AM64.
https://www.ibm.com/developerworks/library/l-systemz/index.html
Do I take it from this that z/Linux is actually
an IBM product? I thought it was something
produced by the freeware community.

If it is an IBM product, does that mean that
IBM-MAIN is the appropriate place to ask
questions about z/Linux?

Thanks. Paul.
Tony Harminc tharminc@gmail.com [hercules-390]
2018-05-24 21:14:51 UTC
Permalink
On 21 May 2018 at 03:52, Mark Morgan Lloyd
Post by ***@yahoo.com.au [hercules-390]
Do I take it from this that z/Linux is actually
an IBM product? I thought it was something
produced by the freeware community.
Remember that technically Linux is open source, not Freeware. Anybody
can ship it as a product free or otherwise, subject to the open source
license and Torvalds ownership of the name "Linux".
zLinux is not an IBM program product, or any kind of IBM production.
IBM takes great care not to become a "distributor" of Linux. They
don't say why, but my guess is that it's to avoid any encounters with
the patent provisions of the GPL.

So IBM contributes code and licenses it under the GPL, as required for
any contributions to Linux), and others like Red Hat, Debian, etc. and
any other less formal undertakings take IBM's and everyone else's
contributions and package them up into "distributions".

Tony H.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2018-05-24 21:35:25 UTC
Permalink
Post by Tony Harminc ***@gmail.com [hercules-390]
zLinux is not an IBM program product, or any kind of IBM production.
IBM takes great care not to become a "distributor" of Linux. They
don't say why, but my guess is that it's to avoid any encounters with
the patent provisions of the GPL.
So IBM contributes code and licenses it under the GPL, as required for
any contributions to Linux), and others like Red Hat, Debian, etc. and
any other less formal undertakings take IBM's and everyone else's
contributions and package them up into "distributions".
They certainly don't do that (have teir own distribution)

However they DO contribute heavily - with access to
priviledged/confidential information - and are (surprisingly) willing to
accomodate the code if it suits their own specs (even if means it helps
running z/Linux under hercules).

z/Linux wouldn't be possible without IBM's contribution.

(Note : I am not affiliated with IBM although I've been working with
them quite a few times)

--Ivan



[Non-text portions of this message have been removed]
Loading...