Re: s390/s390x support implemented

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Hello Harold!
Hello All!

On Monday 09 November 2009 12:29:20 Harold Grovesteen wrote:
> Before getting into the details of what I needed to do, I want to thank 
> all who have contributed to crosstool-ng.  This is a very powerful system.

Cheers! :-)

> Over the weekend I managed to get s390 and s390x to be supported by 
> crosstool-ng.  The tuples end up being s390[x]-ibm-linux-gnu.  Not sure 
> how the ibm part was figured out.  Validated that the libraries in 
> sys-root are ELF s390 32-bit or 64-bit.   This suggests that the tools work.

That's great news! Very nice! :-)

> I had to add CT_DEBUG_CT_SAVE_STEPS="y" to s390[x].sh in function 
> CT_DoArchTupleValues.  Could not find where to set this in the config,  
> Did I miss something?  I tried selecting it in s390[x].in, but this did 
> not seem to work.  Should it have?

CT_DEBUG_CT_SAVE_STEPS is available in :
Paths and misc options  --->
  [*] Debug crosstool-NG
  [ ]   Save intermediate steps

It is needed /only/ when debugging crosstool-NG code, which you may need
to do when adding a new architecture, as you did. But eventually, your
code should just work with SAVE_STEPS disabled.

> Also had problems with libc headers.  Needed to add
> --target=${CT_TARGET} to the configure statement in function
> do_libc_headers in gblibc.sh. This resulted from a conflict in the
> ability of the x86-64 host to support --with-long-double-128 required by
> s390[x].  How this impacts crosstool-ng overall is beyond me.  Without
> --target, the configure checked to determine if the CT_BUILD system (the
> value used for --host) supported -mlong-double-128.  x86-64 does not, so
> the configure failed.  (The build log said that --build, --host and
> --target should be used.  When I observed that --target was missing, I
> supplied it and this got everything to move past that point.)

That's weird. The C library should only know about two things:
 - the machine it is built on (the build machine)
 - the machine it runs on (the host)

There is (should be) no such thing as a 'target' for the C library.
We'll need to see your code to figure out the issue, and find a correct
fix.

> Ran into errors building the debug facilities.  Have not looked at this 
> is detail.  My goal was to build the toolchains and that was 
> successful.  Also, I have no illusion that uclibc or eglibc will work 
> with s390 or bare-metal will work.  I started with glibc because I 
> already knew that could be built with the original crosstool.  My 
> experience in the past suggests that bare-metal will not work out of the 
> box, so to speak.  The configure options

That's perfectly fine with me if uClibc/eglibc/bare-metal/... do not work
in the initial submision. In case someone needs it, it will always be time
to look into it at that moment.

Please, submit your patches, even if not final, we'll discuss them! :-)

> I installed mercurial and cloned the repository, followed by a qinit.  
> Can I add the new modules at this point and have them included in the 
> patches?  How should the patches be created?  I have never used 
> mercurial, so I figured I would ask first rather then doing something 
> that is not usable.

Oh, that's quite easy. First, be sure to work on the 'default' branch.
This is where all development goes on:
    hg update default

Then you create a new 'patch'.
    hg qnew -D -U -e 'patch-name'
        -> 'patch-name' can be anything, the name is local to your tree
        -> the commit message would be smthg like:
           | arch: add support for s390 and s390x
           |
           | Add support for the 32-bit and 64-bit version of the
           | s390 architecture from IBM (pointeur woud be nice).
(note: if you have local changes, you may need to use --force)

Then, once you have your new files edited, you tell Mercurial to track
your new files:
    hg add config/arch/s390.in
    hg add scripts/build/arch/s390.sh
(and subsequently for any other files you added, you can do it all in
 one go, eg: hg add config/arch/s390.in scripts/build/arch/s390.sh)

Then you refresh the current patch:
    hg qrefresh

If possible, separate your work as incremental, self-contained patches.
For example, first add a fix to glibc in a patch, then the new architecture
in a second patch, and so on. Don't hesitate to post, even as a single
patch. we'll look at how to split it if needs be.

And finally, you email your work with:
    hg email --outgoing --intro  \
       --from '"Your Full NAME" <your.email (at) your.domain>'  \
       --to '"Yann E. MORIN" <yann.morin.1998 (at) anciens.enib.fr>'  \
       --cc 'crossgcc (at) sourceware.org'
(replace '(at)' with an actual '@', and put your name and mail address,
 of course!).

Then, we'll be able to review the patches on this list (and I'll get a
direct copy so they stand out in my inbox).

A detailed sample 'session' is in docs/overview.txt, section 'Contributing'.
If you find it disturbing, please speak up, we'll try to make it more clear.

The pros of doing it this way is that:
 - it's easy to review
 - I can easily apply the patch(es) with a simple command line
 - history (repository-wise) is kept
 - most important: you get proper credits in the changelog

Thank you again for your efforts! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq