Paul Edwards wrote:
> GCC 4 complained (on my Linux system) that I didn't have
> various things (gimp etc) installed, which means I would need
> that other software to be ported too, which is not a project
> I want to work on at the moment. However, at least it means
> that i have successfully merged all the GCCMVS changes
> to 3.2.3 in with the (last available) 3.4.6 development, which
> was a precursor to any GCC 4 port anyway. I'll see over time
> how GCC 3.4.6 pans out.
This probably is not gimp (the graphics editor) but gmp (the
multi-precision integer operation library) and mpfr (same for
floating-point). To build any recent GCC you'll indeed need
these two libraries. Fortunately, they're already available
on s390(x) on Linux, and shouldn't really contain anything
that is OS-specific, so porting those to MVS should hopefully
be straightforward ...
> Until then, back at GCC 3.2.3, I have a "need" to make the entry
> point 0 in my MVS modules.
> Currently I generate this:
[snip]
> for a main program. In order to get the entry point to 0, I need to move
> that
> @@MAIN function to the top of the file.
I don't think there is a reliable way to change the sequence of
functions / objects in the output file.
However, it seems to me it shouldn't really be necessary to treat "main"
special. Usually, the "entry point" isn't really "main", but rather some
function in crt0.o, which then in turn *calls* main after all startup
processing has been done. As crt0.o can be (and usually is) completely
written in assembler, you can arrange for everything to be in the sequence
that is required. (On the linker command line, crt0.o would be placed
first, so if the entry point is the first thing in crt0.o it will then
also be the first thing in the executable.)
> And I have another question - where is the code for __asm__?
>
> Currently that is generating garbage for me:
>
> unsigned int bytes = 258;
>
> __asm__("? :");
>
> int main(void)
>
> BYTES EQU *
> DC F'258'
> o...@z
> * Program text area
>
> when done in cross-compiler mode, and need to find out where
> the literal is being translated (or more likely - failing to be
> translated in the first instance). Any idea where that is?
Hmm, this seems to be the bug fixed by Eric Christopher in 2004:
http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg01425.html
> And final thing - the interest in the __asm__ comes from the hope
> that in the generated 370 assembler, it would be possible to have
> the C code interspersed to whatever extent possible. The plan was
> to basically somehow get every line of C code, e.g. "int main(void)"
> above, and automatically generate an:
> __asm__("int main void)");
As you note, this doesn't seem workable as the result wouldn't
be syntactically valid ...
> which gives a syntax error. Any idea how to get the mixed
> C/assembler when I'm running with the "-S" option and don't
> have the luxury of calling the normal "as" which would
> normally handle that?
There doesn't seem to be an easy way to do this from the
compiler. At the time compiler output is generated, the
original source code text isn't even kept any more; you'd
have to go back and re-read the original source files using
the line-number debug data, just as the assembler would ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
