From: "Paul Edwards" <mutazilah@gmail.com>
To: "Ulrich Weigand" <uweigand@de.ibm.com>
Cc: "Daniel Jacobowitz" <drow@false.org>, <gcc@gcc.gnu.org>
Subject: Re: i370 port
Date: Tue, 11 Aug 2009 00:34:00 -0000 [thread overview]
Message-ID: <55E646C333AF44A69A627CE7D64C0ED9@Paullaptop> (raw)
In-Reply-To: <200908101857.n7AIvMgc001040@d12av02.megacenter.de.ibm.com>
> 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 ...
Ok, thanks Ulrich.
>> 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.
Sorry, my question may not have been clear.
When I see main(), I generate the normal MAIN code, and I don't
care where this goes.
However, given that I now know that a main() exists somewhere
in this source file, I need to change the ASM_FILE_START
output.
I expected that the assembler generation wouldn't happen until
after the optimization was completed, and thus, by then, I
would know whether this was a main.
> 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.
That is roughly the case, yes.
> 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.)
Yes, I can do that, but that means I need to have a linker command
line! The way the MVS linker works, I can link my main program,
(which obviously doesn't have crt0 in it), and, thanks to the "END"
statement, I can specify an entry point. This means no complaint
from the linker about a default (and wrong) entry point, and no
need for any linker statements. It all automatically resolves.
It all works really great!
Except - I would ideally like to have an entry point of 0, instead
of the typical "58" or whatever my static variables happen to be.
(my main is normally at the top).
>> 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
Thanks again! That didn't seem to make it into 3.4.6. I was able
to apply most of his stuff to 3.4.6, and I will see how far that gets
me, before trying to find it in 3.2.3.
Or maybe I'll skip it, since the problem doesn't occur on a pure
EBCDIC system. :-)
>> 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 ...
Ok, well - I would be content with just the source line number
appearing in the output assembler. Is this information
available as each assembler line is output?
Thanks. Paul.
next prev parent reply other threads:[~2009-08-10 20:16 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 12:45 Paul Edwards
2009-06-05 14:33 ` Joseph S. Myers
2009-06-05 14:57 ` Paul Edwards
2009-06-05 15:03 ` Joseph S. Myers
2009-06-05 15:24 ` Paul Edwards
2009-06-05 15:47 ` Joseph S. Myers
2009-09-11 17:35 ` i370 port - in search of hooks Paul Edwards
2017-03-31 10:34 ` i370 port Paul Edwards
2009-09-12 12:41 ` Paul Edwards
2009-06-05 15:21 ` Ulrich Weigand
2009-06-05 15:39 ` Paul Edwards
2009-06-05 15:49 ` Daniel Jacobowitz
2009-06-05 15:57 ` Paul Edwards
2009-06-05 20:20 ` Joseph S. Myers
2009-06-05 20:45 ` Paul Edwards
2009-06-06 15:00 ` Paul Edwards
2009-06-15 17:46 ` Ulrich Weigand
2009-06-19 0:06 ` Paul Edwards
2009-06-19 12:28 ` Ulrich Weigand
2009-07-18 11:28 ` Paul Edwards
2009-07-20 14:27 ` Ulrich Weigand
2009-08-08 12:04 ` Paul Edwards
2009-08-10 21:25 ` Ulrich Weigand
2009-08-11 0:34 ` Paul Edwards [this message]
2009-08-11 15:21 ` Ulrich Weigand
2009-08-12 11:52 ` Paul Edwards
2009-08-12 15:27 ` Paolo Bonzini
2009-08-12 16:35 ` Ulrich Weigand
2009-08-12 17:27 ` Paul Edwards
2009-08-12 17:56 ` Paolo Bonzini
2009-08-12 19:46 ` Ulrich Weigand
2009-08-12 20:31 ` Paul Edwards
2009-08-19 12:07 ` Paul Edwards
2009-08-19 12:27 ` Paolo Bonzini
2009-08-20 12:49 ` Paul Edwards
2009-08-20 22:48 ` Ulrich Weigand
2009-08-21 2:37 ` Paul Edwards
2009-08-21 16:46 ` Ulrich Weigand
2009-06-05 15:44 ` Joseph S. Myers
2009-06-05 15:52 ` Paul Edwards
2009-09-08 15:55 ` Paul Edwards
2009-09-14 15:32 ` Ulrich Weigand
2021-09-02 8:15 ` s390 port Paul Edwards
2021-09-02 14:34 ` Ulrich Weigand
2021-09-02 14:50 ` Paul Edwards
2021-09-02 14:53 ` Ulrich Weigand
2021-09-02 15:01 ` Paul Edwards
2021-09-02 15:13 ` Ulrich Weigand
2021-09-02 15:26 ` Paul Edwards
2021-09-02 19:46 ` Ulrich Weigand
2021-09-02 20:05 ` Paul Edwards
2021-09-02 20:16 ` Andreas Schwab
2021-09-03 11:18 ` Ulrich Weigand
2021-09-03 11:35 ` Paul Edwards
2021-09-03 12:12 ` Ulrich Weigand
2021-09-03 12:38 ` Paul Edwards
2021-09-03 12:53 ` Jakub Jelinek
2021-09-03 13:12 ` Paul Edwards
2022-12-20 4:27 ` Paul Edwards
2009-08-23 8:50 i370 port Paul Edwards
2009-08-26 22:13 ` Henrik Sorensen
2009-09-09 22:33 Paul Edwards
2009-09-14 15:42 ` Ulrich Weigand
2009-09-15 12:59 ` Paul Edwards
2009-09-15 13:51 ` Ulrich Weigand
2009-09-17 13:00 ` Paul Edwards
2009-09-17 17:55 ` Ulrich Weigand
2009-09-18 0:35 ` Paul Edwards
2009-09-18 12:06 ` Ulrich Weigand
2009-09-18 12:23 ` Paul Edwards
2009-09-18 13:27 ` Ulrich Weigand
2009-09-18 13:42 ` Paul Edwards
2009-09-18 16:08 ` Ulrich Weigand
2009-09-19 12:57 ` Paul Edwards
2009-09-25 10:19 ` Paul Edwards
2009-09-25 15:20 ` Ulrich Weigand
2009-11-04 5:21 ` Paul Edwards
2009-11-04 16:47 ` Ulrich Weigand
2009-11-09 14:55 ` Paul Edwards
2009-11-09 15:57 ` Ian Lance Taylor
2009-11-09 23:10 ` Paul Edwards
2009-11-10 14:58 ` Paul Edwards
2009-11-10 15:36 ` Ian Lance Taylor
2009-11-10 15:51 ` Paul Edwards
2009-11-10 15:56 ` Ian Lance Taylor
2009-12-02 22:03 ` Paul Edwards
2011-08-13 8:34 ` Paul Edwards
2011-08-15 14:32 ` Ulrich Weigand
2011-08-15 15:26 ` Paul Edwards
2011-08-15 17:23 ` Ulrich Weigand
2011-08-16 11:20 ` Paul Edwards
2011-08-16 13:26 ` Ulrich Weigand
2011-08-18 12:15 ` Paul Edwards
2011-08-18 13:14 ` Ulrich Weigand
2011-08-18 14:18 ` Paul Edwards
2009-09-22 12:31 Paul Edwards
2011-08-20 7:44 Paul Edwards
2011-08-20 10:09 Paul Edwards
2011-08-20 12:15 Paul Edwards
2011-08-22 12:23 ` Ulrich Weigand
2012-04-05 13:32 ` Paul Edwards
2012-04-06 18:13 ` Ulrich Weigand
2012-04-06 5:51 Paul Edwards
2012-04-06 12:49 Paul Edwards
2012-04-06 18:16 ` Ulrich Weigand
2012-04-07 4:12 ` Paul Edwards
2012-04-07 5:45 Paul Edwards
2012-04-08 17:43 ` Ulrich Weigand
2014-02-11 17:01 ` Paul Edwards
2014-02-13 4:23 Paul Edwards
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55E646C333AF44A69A627CE7D64C0ED9@Paullaptop \
--to=mutazilah@gmail.com \
--cc=drow@false.org \
--cc=gcc@gcc.gnu.org \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).