Re: i370 port - constructing compile script

Re: i370 port - constructing compile script

[Paul Edwards]

I've been having fantastic success building gcc.  I have got it
to iterate through the entire build (as far as I can tell) now.

> Then finally I ran into an internal compiler error which I haven't seen
> before.  One of the gcc options must have triggered something off.
> Perhaps it was -Wwrite-strings, or maybe the -O2 (I normally use
> -Os for a completely unrelated reason).  Either way, I need to find
> out how to switch off those flags.  I'll also try to fix the compiler
> internal error in i370.md.

This problem was due to the build being done with 64-bit
long long enabled - something i370.md can't cope with.

I forced it off with these two things:

configure:
  main ()
  {
! long long int i;
    ;
    return 0;
  }
--- 3196,3202 ----
  int
  main ()
  {
! zlong long int i;


hwint.h:
  #if !defined HAVE_LONG_LONG
! # if GCC_VERSION >= 3000 && !PUREISO && defined(WANT64)
  #  define HAVE_LONG_LONG 1
  #  define SIZEOF_LONG_LONG 8


Now at the end of the build, I can save the output, and do a
grep "^i370-mvspdp-gcc" to get all the source files that need to be
compiled.  I could attempt to use the .o files (that are really .s)
directly, but that's not something I really need.

The auto-host.h looks fine, plus I have the generated files.

I still need to clean up the scripts further (the below is a work in
progress), and I need to write the programs that will generate the
compile JCL and then try it out!

Part of the cleanup will hopefully get around the multiple make failures ...

+ make
+ cp gcc/config/i370/dummy_config.h gcc/config.h
+ make
+ cp gcc/config/i370/i370-mvspdp-gcc2 ../mvscross/bin/i370-mvspdp-gcc
+ make

:-)

BFN.  Paul.


Index: gccnew/gcc/configure
diff -c gccnew/gcc/configure:1.1.1.1 gccnew/gcc/configure:1.12
*** gccnew/gcc/configure:1.1.1.1 Thu Jul  9 10:25:05 2009
--- gccnew/gcc/configure Fri Oct 30 12:34:44 2009
***************
*** 2463,2470 ****
--- 2463,2472 ----
  /* end confdefs.h.  */
  #include <stdarg.h>
  #include <stdio.h>
+ #if !defined(__MVS__)
  #include <sys/types.h>
  #include <sys/stat.h>
+ #endif
  /* Most of the following tests are stolen from RCS 5.7's src/conf.sh.  */
  struct buf { int x; };
  FILE * (*rcsopen) (struct buf *, struct stat *, int);
***************
*** 3194,3200 ****
  int
  main ()
  {
! long long int i;
    ;
    return 0;
  }
--- 3196,3202 ----
  int
  main ()
  {
! zlong long int i;
    ;
    return 0;
  }
***************
*** 3377,3383 ****
--- 3379,3387 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
+ #if !defined(__MVS__)
  #include <sys/types.h>
+ #endif


  int
***************
*** 3448,3454 ****
--- 3452,3460 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
+ #if !defined(__MVS__)
  #include <sys/types.h>
+ #endif


  int
***************
*** 3519,3525 ****
--- 3525,3533 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
+ #if !defined(__MVS__)
  #include <sys/types.h>
+ #endif


  int
***************
*** 3590,3596 ****
--- 3598,3606 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
+ #if !defined(__MVS__)
  #include <sys/types.h>
+ #endif


  int
***************
*** 3662,3668 ****
--- 3672,3680 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
+ #if !defined(__MVS__)
  #include <sys/types.h>
+ #endif


  int
***************
*** 3735,3741 ****
--- 3747,3755 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
+ #if !defined(__MVS__)
  #include <sys/types.h>
+ #endif


  int
***************
*** 5656,5662 ****
--- 5670,5678 ----
  if test $ac_cv_header_time = yes; then

  cat >>confdefs.h <<\_ACEOF
+ #if !defined(__MVS__)
  #define TIME_WITH_SYS_TIME 1
+ #endif
  _ACEOF

  fi
***************
*** 6150,6157 ****
--- 6166,6180 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
+ #if !defined(__MVS__)
  #include <sys/types.h>
  #include <sys/param.h>
+ #endif
+ #if defined(__MVS__)
+ #define BIG_ENDIAN 1
+ #define LITTLE_ENDIAN 2
+ #define BYTE_ORDER 1
+ #endif
  int
  main ()
  {
***************
*** 6192,6199 ****
--- 6215,6229 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
+ #if !defined(__MVS__)
  #include <sys/types.h>
  #include <sys/param.h>
+ #endif
+ #if defined(__MVS__)
+ #define BIG_ENDIAN 1
+ #define LITTLE_ENDIAN 2
+ #define BYTE_ORDER 1
+ #endif
  int
  main ()
  {
***************
*** 6731,6738 ****
--- 6761,6770 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
+ #if !defined(__MVS__)
  #include <sys/types.h>
  #include <inttypes.h>
+ #endif
  int
  main ()
  {
***************
*** 6851,6857 ****
--- 6883,6891 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 7051,7057 ****
--- 7085,7093 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
+ #if !defined(__MVS__)
  #include <sys/types.h>
+ #endif

  _ACEOF
  if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
***************
*** 7093,7099 ****
--- 7129,7137 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  /* Thanks to Mike Rendell for this test.  */
+ #if !defined(__MVS__)
  #include <sys/types.h>
+ #endif
  #define NGID 256
  #undef MAX
  #define MAX(x, y) ((x) > (y) ? (x) : (y))
***************
*** 7303,7311 ****
--- 7341,7351 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
+ #if !defined(__MVS__)
  #include <sys/types.h>
  #include <sys/mman.h>
  #include <unistd.h>
+ #endif

  #ifndef MAP_ANONYMOUS
  #define MAP_ANONYMOUS MAP_ANON
***************
*** 7570,7576 ****
--- 7610,7618 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 7644,7650 ****
--- 7686,7694 ----
  else
    cat >conftest.$ac_ext <<_ACEOF
  /* By Ruediger Kuhlmann. */
+       #if !defined(__MVS__)
        #include <sys/types.h>
+       #endif
        #if HAVE_UNISTD_H
        # include <unistd.h>
        #endif
***************
*** 7717,7725 ****
--- 7761,7771 ----
  /* Thanks to Paul Eggert for this test.  */
  #include <stdio.h>
  #include <stdlib.h>
+ #if !defined(__MVS__)
  #include <sys/types.h>
  #include <sys/stat.h>
  #include <sys/wait.h>
+ #endif
  #if HAVE_UNISTD_H
  # include <unistd.h>
  #endif
***************
*** 8998,9004 ****
--- 9044,9052 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */

+ #if !defined(__MVS__)
  #include <sys/types.h>
+ #endif
  #ifdef HAVE_SYS_STAT_H
  # include <sys/stat.h>
  #endif
Index: gccnew/gcc/hwint.h
diff -c gccnew/gcc/hwint.h:1.1.1.2 gccnew/gcc/hwint.h:1.3
*** gccnew/gcc/hwint.h:1.1.1.2 Thu Jul  9 10:27:21 2009
--- gccnew/gcc/hwint.h Mon Nov  2 20:50:44 2009
***************
*** 22,28 ****
     but they're all cross-compile-only.)  Just in case, force a
     constraint violation if that assumption is incorrect.  */
  #if !defined HAVE_LONG_LONG
! # if GCC_VERSION >= 3000 && !PUREISO
  #  define HAVE_LONG_LONG 1
  #  define SIZEOF_LONG_LONG 8
  extern char sizeof_long_long_must_be_8[sizeof(long long) == 8 ? 1 : -1];
--- 22,28 ----
     but they're all cross-compile-only.)  Just in case, force a
     constraint violation if that assumption is incorrect.  */
  #if !defined HAVE_LONG_LONG
! # if GCC_VERSION >= 3000 && !PUREISO && defined(WANT64)
  #  define HAVE_LONG_LONG 1
  #  define SIZEOF_LONG_LONG 8
  extern char sizeof_long_long_must_be_8[sizeof(long long) == 8 ? 1 : -1];
Index: gccnew/gcc/config/i370/build1
diff -c /dev/null gccnew/gcc/config/i370/build1:1.2
*** /dev/null Tue Nov  3 00:56:29 2009
--- gccnew/gcc/config/i370/build1 Tue Nov  3 00:43:52 2009
***************
*** 0 ****
--- 1,6 ----
+ 
./configure --target=i370-mvspdp --prefix=/devel/mvscross --with-sysroot=/devel/mvshead 
 --enable-languages=c
+ make
+ make install
+ mv ../mvscross/bin/i370-mvspdp-gcc ../mvscross/bin/i370-mvspdp-xxx
+ cp gcc/config/i370/i370-mvspdp-gcc1 ../mvscross/bin/i370-mvspdp-gcc
+ cp gcc/config/i370/i370-mvspdp-ar ../mvscross/bin
Index: gccnew/gcc/config/i370/build2
diff -c /dev/null gccnew/gcc/config/i370/build2:1.2
*** /dev/null Tue Nov  3 00:56:29 2009
--- gccnew/gcc/config/i370/build2 Mon Nov  2 23:11:38 2009
***************
*** 0 ****
--- 1,7 ----
+ 
./configure --build=i686-linux --host=i370-mvspdp --target=i370-mvspdp --prefix=/devel/mvshost 
 --enable-languages=c --disable-nls
+
+ make
+ cp gcc/config/i370/dummy_config.h gcc/config.h
+ make
+ cp gcc/config/i370/i370-mvspdp-gcc2 ../mvscross/bin/i370-mvspdp-gcc
+ make
Index: gccnew/gcc/config/i370/dummy_config.h
diff -c /dev/null gccnew/gcc/config/i370/dummy_config.h:1.1
*** /dev/null Tue Nov  3 00:56:29 2009
--- gccnew/gcc/config/i370/dummy_config.h Mon Nov  2 23:11:29 2009
***************
*** 0 ****
--- 1,12 ----
+ #ifndef GCC_CONFIG_H
+ #define GCC_CONFIG_H
+ #ifndef POSIX
+ # define POSIX
+ #endif
+ #include "unixio.h"
+ #include "config/i370/mvspdp.h"
+ #include "auto-host.h"
+ #ifdef IN_GCC
+ # include "ansidecl.h"
+ #endif
+ #endif /* GCC_CONFIG_H */
Index: gccnew/gcc/config/i370/i370-mvspdp-ar
diff -c /dev/null gccnew/gcc/config/i370/i370-mvspdp-ar:1.1
*** /dev/null Tue Nov  3 00:56:29 2009
--- gccnew/gcc/config/i370/i370-mvspdp-ar Tue Nov  3 00:42:23 2009
***************
*** 0 ****
--- 1,2 ----
+ echo ar $*
+ touch $2
Index: gccnew/gcc/config/i370/i370-mvspdp-gcc1
diff -c /dev/null gccnew/gcc/config/i370/i370-mvspdp-gcc1:1.1
*** /dev/null Tue Nov  3 00:56:29 2009
--- gccnew/gcc/config/i370/i370-mvspdp-gcc1 Mon Nov  2 23:08:46 2009
***************
*** 0 ****
--- 1,2 ----
+ i370-mvspdp-xxx -Werror-implicit-function-declaration -DPUREISO -S -I 
/devel/mvshead/usr/include $*
+ #i370-mvspdp-xxx -DPUREISO -S -I /devel/mvshead/usr/include $*
Index: gccnew/gcc/config/i370/i370-mvspdp-gcc2
diff -c /dev/null gccnew/gcc/config/i370/i370-mvspdp-gcc2:1.1
*** /dev/null Tue Nov  3 00:56:29 2009
--- gccnew/gcc/config/i370/i370-mvspdp-gcc2 Mon Nov  2 23:08:46 2009
***************
*** 0 ****
--- 1,2 ----
+ #i370-mvspdp-xxx -Werror-implicit-function-declaration -DPUREISO -S -I 
/devel/mvshead/usr/include $*
+ i370-mvspdp-xxx -DPUREISO -S -I /devel/mvshead/usr/include $*
Index: gccnew/gcc/config/i370/masterbuild
diff -c /dev/null gccnew/gcc/config/i370/masterbuild:1.1
*** /dev/null Tue Nov  3 00:56:29 2009
--- gccnew/gcc/config/i370/masterbuild Mon Nov  2 23:13:48 2009
***************
*** 0 ****
--- 1,11 ----
+ rm -fr gccnew
+ cvs get gccnew
+ cd gccnew
+ gcc/config/i370/build1
+ cd ..
+
+ rm -fr gccnew
+ cvs get gccnew
+ cd gccnew
+ gcc/config/i370/build2
+ cd ..
Index: gccnew/libiberty/configure
diff -c gccnew/libiberty/configure:1.1.1.1 gccnew/libiberty/configure:1.16
*** gccnew/libiberty/configure:1.1.1.1 Thu Jul  9 10:25:05 2009
--- gccnew/libiberty/configure Sat Oct 24 10:00:20 2009
***************
*** 274,279 ****
--- 274,284 ----
  # Factoring default headers for most tests.
  ac_includes_default="\
  #include <stdio.h>
+ #include <stdlib.h>
+ #include <time.h>
+ #include <string.h>
+ #include <signal.h>
+ #include <stdarg.h>
  #if HAVE_SYS_TYPES_H
  # include <sys/types.h>
  #endif
***************
*** 3110,3117 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
! #include <sys/param.h>
  int
  main ()
  {
--- 3115,3125 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
! #include <sys/param.h>*/
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1
  int
  main ()
  {
***************
*** 3143,3150 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
! #include <sys/param.h>
  int
  main ()
  {
--- 3151,3161 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
! #include <sys/param.h>*/
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1
  int
  main ()
  {
***************
*** 4163,4169 ****
--- 4174,4189 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #else
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <time.h>
+ #include <string.h>
+ #include <signal.h>
+ #include <stdarg.h>
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 4424,4429 ****
--- 4444,4457 ----
      libiberty_cv_var_sys_errlist=yes
      ;;

+   *-*-mvs*)
+     # MVS has no extensions
+     ac_cv_func_vfork_works=no
+     libiberty_cv_var_sys_nerr=no
+     libiberty_cv_var_sys_errlist=no
+     libiberty_cv_var_sys_siglist=no
+     ;;
+
    *-*-*vms*)
      # Under VMS, vfork works very different than on Unix. The standard 
test
      # won't work, and it isn't easily adaptable. It makes more sense to
***************
*** 4590,4596 ****
--- 4618,4633 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #else
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <time.h>
+ #include <string.h>
+ #include <signal.h>
+ #include <stdarg.h>
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 4926,4932 ****
--- 4963,4971 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 5256,5262 ****
--- 5295,5303 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 5555,5561 ****
--- 5596,5611 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #else
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <time.h>
+ #include <string.h>
+ #include <signal.h>
+ #include <stdarg.h>
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */

Re: i370 port - constructing compile script

[Paul Edwards]

Hi Ulrich.  I've had considerable success in this process.  I've
now reached the point where I seem to have a correctly
generated config.h in libiberty and correct auto-host.h in gcc,
which is one of the aims in order to get an eventual link on
MVS.

>> However, it meant that I could look at the auto-host.h and
>> see what it had come up with.  It correctly figured out that
>> I didn't have a raft of header files, but still thought I had
>> lots of functions like fork() and getrusage().
>>
>> I suspect that is because my fake compiler is compiling
>> with the "-S' option and returning success when it's after
>> a link failure.

> OK.  I thought with the fake as and ld scripts, you should
> no longer need a "fake compiler" script?

I haven't got to the stage of playing around with that yet.

> But even so, you're right that the "fake linker" will not
> actually check whether symbols are present in your
> library ...

>> I had an idea - maybe I can have warnings switched on
>> for functions without prototypes, and then my dummy
>> compiler trap the output and do a "wc" and if there's
>> an unexpectedly high number of lines, then it can exit
>> with failure.

> Or simply use -Werror when doing test compiles in
> configure.

Turns out that -Werror-implicit-function-declaration wasn't
sufficient.  Because "configure" dutifully goes and inserts
its own declaration for the non-existant functions!

However, more intrusive code:

+ #if !defined(__MVS__)
  char $ac_func ();
+ #else
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <time.h>
+ #include <string.h>
+ #include <signal.h>
+ #include <stdarg.h>
+ #endif

got past that problem, such that I could get the config
file I needed.  I needed to put in the standard includes,
otherwise it thought that I didn't even have memcmp!

Any suggestion on how to make this less intrusive?  Or
perhaps is it logical to have a generic "trap at compile
time instead of link time" configure option for other
environments also?  Maybe we could have two variables,
a BEFORE_AC_FUNC and AFTER_AC_FUNC which
are defined in all those tests, and can be set to open
comment and close comment + includes to achieve
the above effect.  Or maybe I should simply pass over
the configure script doing that substitution, since the
string to search for is unique and consistent, ie
grep "^char \$ac_func" configure

char $ac_func ();
/* The GNU C library define
    to always fail with ENO
    something starting with
#if defined (__stub_$ac_fun
choke me
#else
char (*f) () = $ac_func;

I was thinking that maybe what I should do is in the fake
linker, see what the output executable is.  If the output
executable is a conftest, then do a scan of the VCONs
(external references) in the assembler making sure they
are all C90.  But that seems to be the wrong approach to
me.  If there's going to be a list of C90 functions and
variables it should probably be in configure.ac I think.

Speaking of which.  When I was putting in the intrusive
code, I saw things like newlib and Vxworks which had
explicit mention and explicit settings for various things.
Perhaps I should be doing something like that too rather
than faking things to get them through?  That would lower
the barrier for an arbitrary and possibly complicated target
with no extensions.

However, let's stay on the current track, so that e.g. this
could be used to target mvsdignus, which probably does
have various extensions, and they may wish to make use
of them in their MVS build.  Thus, it needs to go through
the detection process.

Assuming that detection process has worked, and the
config.h file is correctly set, then I run into the next problem.

A stack of C files in libiberty failed to compile, because they
have extensions in them.  E.g. make-temp-file.c calls
access().  I've never noticed them before because I've never
included them in my links, because they are not required
on MVS.  Even totally unrelated things like pex-unix.c are
being compiled.  So what is the best way of switching the
source code to compile?

It is at this stage that I wish to create a single executable,
so would want the fake linker to do a tar or zip.  (or simply
an echo, I'm flexible on that).  So those failing files would
presumably be omitted from that anyway?  Or are they
normally unconditionally compiled and linked?

Finally, even with this in place, the build process stopped at
the next roadblock.  The file "genmodes.c" couldn't be
compiled.  I was surprised to see that it was being compiled
with i370-mvspdp-gcc.  The genmodes "needs" to be run on
Unix still.  It's only the source code that IT generates that
needs to be cross-compiled.

Regardless, genmodes.c didn't compile because auto-build.h
correctly detected that my Unix system has <sys/types.h>
etc, but my own header files don't have that, so a cross
compile doesn't work.

How does that normally work when cross-compiling a host?

BTW, I really like the idea of the fake linker zipping up all the
generated assembler as it goes through, which is ultimately
what I need to send up to MVS.  The JCL can be generated
from "unzip -v" as an entirely separate, and unobtrusive, process.

Thanks for all your assistance in getting this set up.  It seems
there is light at the end of the tunnel for getting this properly
integrated into the normal build process.  :-)

BFN.  Paul.





Index: gcc/configure
===================================================================
RCS file: /cvsroot/gccnew/gcc/configure,v
retrieving revision 1.1.1.1
retrieving revision 1.10
diff -c -r1.1.1.1 -r1.10
*** gcc/configure 9 Jul 2009 00:25:05 -0000 1.1.1.1
--- gcc/configure 21 Oct 2009 21:41:11 -0000 1.10
***************
*** 2463,2470 ****
  /* end confdefs.h.  */
  #include <stdarg.h>
  #include <stdio.h>
! #include <sys/types.h>
! #include <sys/stat.h>
  /* Most of the following tests are stolen from RCS 5.7's src/conf.sh.  */
  struct buf { int x; };
  FILE * (*rcsopen) (struct buf *, struct stat *, int);
--- 2463,2470 ----
  /* end confdefs.h.  */
  #include <stdarg.h>
  #include <stdio.h>
! /*#include <sys/types.h>
! #include <sys/stat.h>*/
  /* Most of the following tests are stolen from RCS 5.7's src/conf.sh.  */
  struct buf { int x; };
  FILE * (*rcsopen) (struct buf *, struct stat *, int);
***************
*** 3377,3383 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3377,3383 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 3448,3454 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3448,3454 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 3519,3525 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3519,3525 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 3590,3596 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3590,3596 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 3662,3668 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3662,3668 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 3735,3741 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3735,3741 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 5656,5662 ****
  if test $ac_cv_header_time = yes; then

  cat >>confdefs.h <<\_ACEOF
! #define TIME_WITH_SYS_TIME 1
  _ACEOF

  fi
--- 5656,5662 ----
  if test $ac_cv_header_time = yes; then

  cat >>confdefs.h <<\_ACEOF
! /*#define TIME_WITH_SYS_TIME 1*/
  _ACEOF

  fi
***************
*** 6150,6157 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
! #include <sys/param.h>
  int
  main ()
  {
--- 6150,6160 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
! #include <sys/param.h>*/
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1
  int
  main ()
  {
***************
*** 6192,6199 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
! #include <sys/param.h>
  int
  main ()
  {
--- 6195,6205 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
! #include <sys/param.h>*/
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1
  int
  main ()
  {
***************
*** 6731,6738 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
! #include <inttypes.h>
  int
  main ()
  {
--- 6737,6744 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
! #include <inttypes.h>*/
  int
  main ()
  {
***************
*** 6851,6857 ****
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
! char $ac_func ();
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
--- 6857,6863 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
! /*char $ac_func ();*/
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 7051,7057 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>

  _ACEOF
  if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
--- 7057,7063 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>*/

  _ACEOF
  if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
***************
*** 7093,7099 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  /* Thanks to Mike Rendell for this test.  */
! #include <sys/types.h>
  #define NGID 256
  #undef MAX
  #define MAX(x, y) ((x) > (y) ? (x) : (y))
--- 7099,7105 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  /* Thanks to Mike Rendell for this test.  */
! /*#include <sys/types.h>*/
  #define NGID 256
  #undef MAX
  #define MAX(x, y) ((x) > (y) ? (x) : (y))
***************
*** 7303,7311 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
  #include <sys/mman.h>
! #include <unistd.h>

  #ifndef MAP_ANONYMOUS
  #define MAP_ANONYMOUS MAP_ANON
--- 7309,7317 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
  #include <sys/mman.h>
! #include <unistd.h>*/

  #ifndef MAP_ANONYMOUS
  #define MAP_ANONYMOUS MAP_ANON
***************
*** 7570,7576 ****
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
! char $ac_func ();
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
--- 7576,7582 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
! /*char $ac_func ();*/
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 7644,7650 ****
  else
    cat >conftest.$ac_ext <<_ACEOF
  /* By Ruediger Kuhlmann. */
!       #include <sys/types.h>
        #if HAVE_UNISTD_H
        # include <unistd.h>
        #endif
--- 7650,7656 ----
  else
    cat >conftest.$ac_ext <<_ACEOF
  /* By Ruediger Kuhlmann. */
!       /*#include <sys/types.h>*/
        #if HAVE_UNISTD_H
        # include <unistd.h>
        #endif
***************
*** 7717,7725 ****
  /* Thanks to Paul Eggert for this test.  */
  #include <stdio.h>
  #include <stdlib.h>
! #include <sys/types.h>
  #include <sys/stat.h>
! #include <sys/wait.h>
  #if HAVE_UNISTD_H
  # include <unistd.h>
  #endif
--- 7723,7731 ----
  /* Thanks to Paul Eggert for this test.  */
  #include <stdio.h>
  #include <stdlib.h>
! /*#include <sys/types.h>
  #include <sys/stat.h>
! #include <sys/wait.h>*/
  #if HAVE_UNISTD_H
  # include <unistd.h>
  #endif
***************
*** 8998,9004 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */

! #include <sys/types.h>
  #ifdef HAVE_SYS_STAT_H
  # include <sys/stat.h>
  #endif
--- 9004,9010 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */

! /*#include <sys/types.h>*/
  #ifdef HAVE_SYS_STAT_H
  # include <sys/stat.h>
  #endif
Index: libiberty/argv.c
===================================================================
RCS file: /cvsroot/gccnew/libiberty/argv.c,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -c -r1.1.1.2 -r1.2
*** libiberty/argv.c 9 Jul 2009 00:27:13 -0000 1.1.1.2
--- libiberty/argv.c 21 Oct 2009 22:40:29 -0000 1.2
***************
*** 48,55 ****

  #endif /* ANSI_PROTOTYPES */

! #if defined PUREISO
! extern char *strdup ();  /* Duplicate a string */
  #endif

  #ifndef NULL
--- 48,55 ----

  #endif /* ANSI_PROTOTYPES */

! #if !defined(HAVE_STRDUP)
! extern char *strdup ();     /* Duplicate a string */
  #endif

  #ifndef NULL
Index: libiberty/choose-temp.c
===================================================================
RCS file: /cvsroot/gccnew/libiberty/choose-temp.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -c -r1.1.1.1 -r1.2
*** libiberty/choose-temp.c 9 Jul 2009 00:25:05 -0000 1.1.1.1
--- libiberty/choose-temp.c 21 Oct 2009 23:32:54 -0000 1.2
***************
*** 53,58 ****
--- 53,59 ----

  */

+ #if !defined(PUREISO)
  char *
  choose_temp_base ()
  {
***************
*** 70,72 ****
--- 71,74 ----
      abort ();
    return temp_filename;
  }
+ #endif
Index: libiberty/configure
===================================================================
RCS file: /cvsroot/gccnew/libiberty/configure,v
retrieving revision 1.1.1.1
retrieving revision 1.14
diff -c -r1.1.1.1 -r1.14
*** libiberty/configure 9 Jul 2009 00:25:05 -0000 1.1.1.1
--- libiberty/configure 22 Oct 2009 03:02:06 -0000 1.14
***************
*** 274,279 ****
--- 274,284 ----
  # Factoring default headers for most tests.
  ac_includes_default="\
  #include <stdio.h>
+ #include <stdlib.h>
+ #include <time.h>
+ #include <string.h>
+ #include <signal.h>
+ #include <stdarg.h>
  #if HAVE_SYS_TYPES_H
  # include <sys/types.h>
  #endif
***************
*** 3110,3117 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
! #include <sys/param.h>
  int
  main ()
  {
--- 3115,3125 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
! #include <sys/param.h>*/
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1
  int
  main ()
  {
***************
*** 3143,3150 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
! #include <sys/param.h>
  int
  main ()
  {
--- 3151,3161 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
! #include <sys/param.h>*/
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1
  int
  main ()
  {
***************
*** 4163,4169 ****
--- 4174,4189 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #else
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <time.h>
+ #include <string.h>
+ #include <signal.h>
+ #include <stdarg.h>
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 4424,4429 ****
--- 4444,4457 ----
      libiberty_cv_var_sys_errlist=yes
      ;;

+   *-*-mvs*)
+     # MVS has no extensions
+     ac_cv_func_vfork_works=no
+     libiberty_cv_var_sys_nerr=no
+     libiberty_cv_var_sys_errlist=no
+     libiberty_cv_var_sys_siglist=no
+     ;;
+
    *-*-*vms*)
      # Under VMS, vfork works very different than on Unix. The standard 
test
      # won't work, and it isn't easily adaptable. It makes more sense to
***************
*** 4590,4596 ****
--- 4618,4633 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #else
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <time.h>
+ #include <string.h>
+ #include <signal.h>
+ #include <stdarg.h>
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 4926,4932 ****
--- 4963,4971 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 5256,5262 ****
--- 5295,5303 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
***************
*** 5555,5561 ****
--- 5596,5611 ----
  #endif
  /* We use char because int might match the return type of a gcc2
     builtin and then its argument prototype would still apply.  */
+ #if !defined(__MVS__)
  char $ac_func ();
+ #else
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <time.h>
+ #include <string.h>
+ #include <signal.h>
+ #include <stdarg.h>
+ #endif
  /* The GNU C library defines this for functions which it implements
      to always fail with ENOSYS.  Some functions are actually named
      something starting with __ and the normal name is an alias.  */
Index: libiberty/fdmatch.c
===================================================================
RCS file: /cvsroot/gccnew/libiberty/fdmatch.c,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -c -r1.1.1.2 -r1.2
*** libiberty/fdmatch.c 9 Jul 2009 00:27:10 -0000 1.1.1.2
--- libiberty/fdmatch.c 21 Oct 2009 23:32:54 -0000 1.2
***************
*** 53,58 ****
--- 53,59 ----
  #include <sys/stat.h>
  #endif

+ #if !defined(PUREISO)
  int fdmatch (fd1, fd2)
   int fd1;
   int fd2;
***************
*** 72,74 ****
--- 73,76 ----
        return (0);
      }
  }
+ #endif
Index: libiberty/getpwd.c
===================================================================
RCS file: /cvsroot/gccnew/libiberty/getpwd.c,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -c -r1.1.1.2 -r1.2
*** libiberty/getpwd.c 9 Jul 2009 00:27:12 -0000 1.1.1.2
--- libiberty/getpwd.c 21 Oct 2009 23:32:54 -0000 1.2
***************
*** 65,70 ****
--- 65,71 ----
     to the user.  Yield the working directory if successful; otherwise,
     yield 0 and set errno.  */

+ #if !defined(PUREISO)
  char *
  getpwd ()
  {
***************
*** 105,110 ****
--- 106,112 ----
      }
    return p;
  }
+ #endif

  #else /* VMS || _WIN32 && !__CYGWIN__ */

Index: libiberty/make-relative-prefix.c
===================================================================
RCS file: /cvsroot/gccnew/libiberty/make-relative-prefix.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -c -r1.1.1.1 -r1.2
*** libiberty/make-relative-prefix.c 9 Jul 2009 00:25:05 -0000 1.1.1.1
--- libiberty/make-relative-prefix.c 22 Oct 2009 03:20:40 -0000 1.2
***************
*** 222,227 ****
--- 222,228 ----

     If no relative prefix can be found, return NULL.  */

+ #if !defined(__MVS__)
  char *
  make_relative_prefix (progname, bin_prefix, prefix)
       const char *progname;
***************
*** 394,396 ****
--- 395,398 ----

    return ret;
  }
+ #endif
Index: libiberty/make-temp-file.c
===================================================================
RCS file: /cvsroot/gccnew/libiberty/make-temp-file.c,v
retrieving revision 1.1.1.2
retrieving revision 1.2
diff -c -r1.1.1.2 -r1.2
*** libiberty/make-temp-file.c 9 Jul 2009 00:27:12 -0000 1.1.1.2
--- libiberty/make-temp-file.c 22 Oct 2009 03:20:40 -0000 1.2
***************
*** 57,62 ****
--- 57,63 ----
  #define TEMP_FILE "ccXXXXXX"
  #define TEMP_FILE_LEN (sizeof(TEMP_FILE) - 1)

+ #if !defined(__MVS__)
  /* Subroutine of choose_tmpdir.
     If BASE is non-NULL, return it.
     Otherwise it checks if DIR is a usable directory.
***************
*** 179,181 ****
--- 180,183 ----
      abort ();
    return temp_filename;
  }
+ #endif
Index: libiberty/pex-unix.c
===================================================================
RCS file: /cvsroot/gccnew/libiberty/pex-unix.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -c -r1.1.1.1 -r1.2
*** libiberty/pex-unix.c 9 Jul 2009 00:25:05 -0000 1.1.1.1
--- libiberty/pex-unix.c 22 Oct 2009 03:20:40 -0000 1.2
***************
*** 47,52 ****
--- 47,53 ----
  extern int execv ();
  extern int execvp ();

+ #if !defined(__MVS__)
  int
  pexecute (program, argv, this_pname, temp_base, errmsg_fmt, errmsg_arg, 
flags)
       const char *program;
***************
*** 164,166 ****
--- 165,168 ----
    pid = waitpid (pid, status, 0);
    return pid;
  }
+ #endif

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> Hi Ulrich.  I've had considerable success in this process.  I've
> now reached the point where I seem to have a correctly
> generated config.h in libiberty and correct auto-host.h in gcc,
> which is one of the aims in order to get an eventual link on
> MVS.

OK, good to hear you're making progress!

> Any suggestion on how to make this less intrusive?  Or
> perhaps is it logical to have a generic "trap at compile
> time instead of link time" configure option for other
> environments also?  Maybe we could have two variables,
> a BEFORE_AC_FUNC and AFTER_AC_FUNC which
> are defined in all those tests, and can be set to open
> comment and close comment + includes to achieve
> the above effect.

Well, this is generated from the AC_CHECK_FUNCS macro
in gcc/configure.ac.  This macro is implemented by the
autoconf infrastructure and appears to always use link
tests (most GCC-specific tests seem to be compile-only
tests, fortunately).

I guess it might be interesting to see whether this can
be replaced by compile-time tests, either by using a
different mechanism in gcc/configure.ac, or else by
overriding the AC_CHECK_FUNCS implementation in GCC's
aclocal.m4 macro set ...

Unfortunately, I'm not really an autoconf expert either.
Maybe someone else on the list is able to help with this.

> I was thinking that maybe what I should do is in the fake
> linker, see what the output executable is.  If the output
> executable is a conftest, then do a scan of the VCONs
> (external references) in the assembler making sure they
> are all C90.  But that seems to be the wrong approach to
> me.  If there's going to be a list of C90 functions and
> variables it should probably be in configure.ac I think.

This might also be an option.  I guess in principle your
"fake linker" might even be able to look at the target
libraries (either directly, or via a list of exported
symbols that is provided by some other tool) ...

> Speaking of which.  When I was putting in the intrusive
> code, I saw things like newlib and Vxworks which had
> explicit mention and explicit settings for various things.
> Perhaps I should be doing something like that too rather
> than faking things to get them through?  That would lower
> the barrier for an arbitrary and possibly complicated target
> with no extensions.

I don't see this is the main gcc/configure.  However, some
of the target libraries, in particular libiberty, do have
hard-coded results for certain platforms.  This might not
really be a bad idea ...

> A stack of C files in libiberty failed to compile, because they
> have extensions in them.  E.g. make-temp-file.c calls
> access().  I've never noticed them before because I've never
> included them in my links, because they are not required
> on MVS.  Even totally unrelated things like pex-unix.c are
> being compiled.  So what is the best way of switching the
> source code to compile?

Hmmm, the access() use probably needs to be guarded by a configure
check.  Or else you might provide a MVS-specific implementation of
"access" (if that is possible), and compile it into libiberty by
providing an EXTRA_OFILES setting in a host makefile fragment;
in 3.4 these are set in config.table:
case "${host}" in
  rs6000-ibm-aix3.1 | rs6000-ibm-aix)
                        frag=mh-aix ;;
  *-*-cxux7*)           frag=mh-cxux7 ;;
  *-*-freebsd2.1.*)     frag=mh-fbsd21 ;;
  *-*-freebsd2.2.[012]) frag=mh-fbsd21 ;;
  i370-*-opened*)       frag=mh-openedition ;;
  i[34567]86-*-windows*)        frag=mh-windows ;;
esac

As to the pex-unix.c, you certainly should provide a MVS-specific
version of the PEX callbacks.  They are selected in configure.ac:

# Figure out which version of pexecute to use.
case "${host}" in
     *-*-mingw* | *-*-winnt*)   pexecute=pex-win32.o  ;;
     *-*-msdosdjgpp*)           pexecute=pex-djgpp.o  ;;
     *-*-msdos*)                pexecute=pex-msdos.o  ;;
     *-*-os2-emx*)              pexecute=pex-os2.o    ;;
     *)                         pexecute=pex-unix.o   ;;
esac

Your MVS version might be just a dummy that always fails.
Even better would be a version that actually works; in this
case all the "single-exectuable" hacks would become superfluous.

Note that e.g. pex-msdos.c implements the required callbacks
solely in terms of the C99 "system" routine.  If you at least
have this facility available on MVS, you might be able to just
use the msdos version?

> Finally, even with this in place, the build process stopped at
> the next roadblock.  The file "genmodes.c" couldn't be
> compiled.  I was surprised to see that it was being compiled
> with i370-mvspdp-gcc.  The genmodes "needs" to be run on
> Unix still.  It's only the source code that IT generates that
> needs to be cross-compiled.

If this happens, then something went very wrong during configure.
Did you make sure to use the proper build / host / target flags?
In particular, the --build= configure argument must be present
and refer to the build architecture.  This is used to determine
which architecture to build the generator programs for.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

Hi Ulrich.

I'll try out some of those things.  I have some initial
comments.

> Hmmm, the access() use probably needs to be guarded by a configure
> check.  Or else you might provide a MVS-specific implementation of
> "access" (if that is possible), and compile it into libiberty by
> providing an EXTRA_OFILES setting in a host makefile fragment;

Probably too many of them.  Just like open() etc in GCC main.
I'll see what can be faked up, now that I know those object files
are basically mandatory.

> in 3.4 these are set in config.table:
> case "${host}" in
>  rs6000-ibm-aix3.1 | rs6000-ibm-aix)
>                        frag=mh-aix ;;
>  *-*-cxux7*)           frag=mh-cxux7 ;;
>  *-*-freebsd2.1.*)     frag=mh-fbsd21 ;;
>  *-*-freebsd2.2.[012]) frag=mh-fbsd21 ;;
>  i370-*-opened*)       frag=mh-openedition ;;
>  i[34567]86-*-windows*)        frag=mh-windows ;;
> esac
> 
> As to the pex-unix.c, you certainly should provide a MVS-specific
> version of the PEX callbacks.  They are selected in configure.ac:
> 
> # Figure out which version of pexecute to use.
> case "${host}" in
>     *-*-mingw* | *-*-winnt*)   pexecute=pex-win32.o  ;;
>     *-*-msdosdjgpp*)           pexecute=pex-djgpp.o  ;;
>     *-*-msdos*)                pexecute=pex-msdos.o  ;;
>     *-*-os2-emx*)              pexecute=pex-os2.o    ;;
>     *)                         pexecute=pex-unix.o   ;;
> esac

Ok, thanks.

> Your MVS version might be just a dummy that always fails.

Ok.

> Even better would be a version that actually works; in this
> case all the "single-exectuable" hacks would become superfluous.

Having a single executable, especially in my environment where
only assembler code is ever generated, has its own merits even if
a working system() can be done in the future.

> Note that e.g. pex-msdos.c implements the required callbacks
> solely in terms of the C99 "system" routine.  If you at least
> have this facility available on MVS, you might be able to just
> use the msdos version?

I don't have a working system that can execute another C program
yet.  Note that C90 leaves the behaviour of system() as
"implementation defined".  Well, on my system, I can do a system()
to call some simple programs that clear the screen.  In one
environment on my system, anyway.  :-)

>> Finally, even with this in place, the build process stopped at
>> the next roadblock.  The file "genmodes.c" couldn't be
>> compiled.  I was surprised to see that it was being compiled
>> with i370-mvspdp-gcc.  The genmodes "needs" to be run on
>> Unix still.  It's only the source code that IT generates that
>> needs to be cross-compiled.
> 
> If this happens, then something went very wrong during configure.
> Did you make sure to use the proper build / host / target flags?
> In particular, the --build= configure argument must be present
> and refer to the build architecture.  This is used to determine
> which architecture to build the generator programs for.

Yes, I have all 3 specified, with --build of i686-linux.  Now that I
know that the generator files are meant to be built with the i686
gcc, I'll try to find out where it's picking that up from.

BFN.  Paul.

Re: i370 port - constructing compile script

[Paul Edwards]

> As to the pex-unix.c, you certainly should provide a MVS-specific
> version of the PEX callbacks.  They are selected in configure.ac:
> 
> # Figure out which version of pexecute to use.
> case "${host}" in
>     *-*-mingw* | *-*-winnt*)   pexecute=pex-win32.o  ;;
>     *-*-msdosdjgpp*)           pexecute=pex-djgpp.o  ;;
>     *-*-msdos*)                pexecute=pex-msdos.o  ;;
>     *-*-os2-emx*)              pexecute=pex-os2.o    ;;
>     *)                         pexecute=pex-unix.o   ;;
> esac
> 
> Your MVS version might be just a dummy that always fails.
> Even better would be a version that actually works; in this
> case all the "single-exectuable" hacks would become superfluous.
> 
> Note that e.g. pex-msdos.c implements the required callbacks
> solely in terms of the C99 "system" routine.  If you at least
> have this facility available on MVS, you might be able to just
> use the msdos version?

I tried using the MSDOS version and it had non-C90 compile
errors.  But provding a dummy pex-mvs is fine.

>> Finally, even with this in place, the build process stopped at
>> the next roadblock.  The file "genmodes.c" couldn't be
>> compiled.  I was surprised to see that it was being compiled
>> with i370-mvspdp-gcc.  The genmodes "needs" to be run on
>> Unix still.  It's only the source code that IT generates that
>> needs to be cross-compiled.
> 
> If this happens, then something went very wrong during configure.
> Did you make sure to use the proper build / host / target flags?
> In particular, the --build= configure argument must be present
> and refer to the build architecture.  This is used to determine
> which architecture to build the generator programs for.

Ok, perhaps this error was because when I hit errors in intl,
which I've never used before, I just went to the gcc directory and
did a make.

Regardless, I added a stack of touch xxx.o in the intl directory
after the failure of the first make, which allowed me to do a second
make, and then it was satisfied with the intl directory and moved
on to the gcc directory, where it did in fact invoke the correct
gcc rather than the cross-compiler.

The next thing I hit was that genmodes didn't compile because
there were conflicts between the strsignal function in the
Linux include files and the system.h.  Looking at the system.h,
it was including things in because it thought that the prototypes
didn't exist.  Which would have been true for the cross-compiler,
but isn't true for a native gcc.  How are those two different things
meant to be reconciled?

Thanks.  Paul.

Re: i370 port - constructing compile script

[Ian Lance Taylor]

"Paul Edwards" <mutazilah@gmail.com> writes:

> The next thing I hit was that genmodes didn't compile because
> there were conflicts between the strsignal function in the
> Linux include files and the system.h.  Looking at the system.h,
> it was including things in because it thought that the prototypes
> didn't exist.  Which would have been true for the cross-compiler,
> but isn't true for a native gcc.  How are those two different things
> meant to be reconciled?

When you run the configure script for building the native gcc, it is
supposed to detect that the prototypes exist.  The configure script
will do this by running the cross-compiler being used to build the
native gcc.  The cross-compiler is expected to be using the
appropriate header files, and thus to see the declarations.

Ian

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> Ok, perhaps this error was because when I hit errors in intl,
> which I've never used before, I just went to the gcc directory and
> did a make.
> 
> Regardless, I added a stack of touch xxx.o in the intl directory
> after the failure of the first make, which allowed me to do a second
> make, and then it was satisfied with the intl directory and moved
> on to the gcc directory, where it did in fact invoke the correct
> gcc rather than the cross-compiler.

If you use --disable-nls on the configure line, the intl directory
should be skipped ...

> The next thing I hit was that genmodes didn't compile because
> there were conflicts between the strsignal function in the
> Linux include files and the system.h.  Looking at the system.h,
> it was including things in because it thought that the prototypes
> didn't exist.  Which would have been true for the cross-compiler,
> but isn't true for a native gcc.  How are those two different things
> meant to be reconciled?

Before including "system.h", generator files include "bconfig.h"
where core compiler files include "config.h".  The former then
in turn includes "auto-build.h", while the latter includes
"auto-host.h".  These contain the configure results for the
--build= and --host= systems, respectively.

All this should work automatically if you use the proper
configure options, so something odd must be going on ...

Are you running the top-level configure?  (If you run a
subdirectory configure, e.g. the one in gcc/, directly,
things may not work correctly.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

> If you use --disable-nls on the configure line, the intl directory
> should be skipped ...

Ok, that's working.

>> The next thing I hit was that genmodes didn't compile because
>> there were conflicts between the strsignal function in the
>> Linux include files and the system.h.  Looking at the system.h,
>> it was including things in because it thought that the prototypes
>> didn't exist.  Which would have been true for the cross-compiler,
>> but isn't true for a native gcc.  How are those two different things
>> meant to be reconciled?
> 
> Before including "system.h", generator files include "bconfig.h"
> where core compiler files include "config.h".  The former then
> in turn includes "auto-build.h", while the latter includes
> "auto-host.h".

And this much is fine.

> These contain the configure results for the
> --build= and --host= systems, respectively.

However, the auto-build.h is not detecting the all the includes etc.
So while auto-host.h has a #define HAVE_DECL_CALLOC 1, the
auto-build.h has it as 0.

There's nothing in config.log showing a CALLOC of 0.  So where
can I find out what's setting this?

> All this should work automatically if you use the proper
> configure options, so something odd must be going on ...

Yeah, I've probably changed something when making all the
additions to get my new target and that is now interfering.
Something similar to that dummy pwait.  Now I've got to find
it and reverse it (or mask it out).

> Are you running the top-level configure?  (If you run a
> subdirectory configure, e.g. the one in gcc/, directly,
> things may not work correctly.)

Yes I am.

One other thing I did - I compiled the cross-compiler, and installed it.

Then I wiped out the directory and extracted a fresh version and did
the configure for building the host.  I thought that would make things
clean.  But maybe the previous build had the correct auto-build.h
that I need, and without it I get some sort of dummy auto-build.h?

BFN.  Paul.

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> > Are you running the top-level configure?  (If you run a
> > subdirectory configure, e.g. the one in gcc/, directly,
> > things may not work correctly.)
> 
> Yes I am.
> 
> One other thing I did - I compiled the cross-compiler, and installed it.
> 
> Then I wiped out the directory and extracted a fresh version and did
> the configure for building the host.  I thought that would make things
> clean.  But maybe the previous build had the correct auto-build.h
> that I need, and without it I get some sort of dummy auto-build.h?

No, you definitely should start from a clean build directory when
building the native compiler.  In fact, you should not build in the
source directory at all; this has been known to not always work
reliably for GCC, in particular when doing more complex builds ...

This means that if your GCC source tree resides in a directory, say,
  ~/gcc-src
you should *not* run ./configure while in ~/gcc-src.  Instead, you
should create a second, empty directory
  ~/gcc-build
(which is not a subdirectory of ~/gcc-src), and run
  ../gcc-src/configure ...
while in ~/gcc-build.

The "make" process then operates wholly in the build directory, without
changing anything in the source directory.  For doing the second compiler
build, you can either delete the build directory, or just use yet another
directory.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

> This means that if your GCC source tree resides in a directory, say,
>  ~/gcc-src
> you should *not* run ./configure while in ~/gcc-src.  Instead, you
> should create a second, empty directory
>  ~/gcc-build
> (which is not a subdirectory of ~/gcc-src), and run
>  ../gcc-src/configure ...
> while in ~/gcc-build.

Ok, I tried that, and it still didn't fix the problem.  Not only that, after
I fixed the problem (below), I ended up getting an error that way.
input.h not found or something like that.  So I went back to the
source tree build, and made quite a lot of progress.

First of all, the problem was obvious in hindsight.  I had commented
out a whole lot of stuff in configure in order to stop things from being
auto-detected.  However, that was interfering with the configure for
the build environment!!!

So I put #if !defined(__MVS__) around everything that I was commenting
out, and I was able to get past genmodes and on to the next error.

The next error was that it was trying to use ino_t in a header file, which
doesn't exist.  The way I got around this using my own procedure was
to create a unixio.h which has the various Posix stuff in it.  E.g. I have
an open() that calls fopen().  ino_t is one of the typedefs there.

Anyway, I put a #include "unixio.h" into config.h and got past that
problem.  I don't think that was the right thing to do though, because
that is a generated file.  What should I have done instead?

A #include of "config/i370/mvspdp.h" got around the next problem,
and I think I need to do more investigation as to why that was needed.

Then finally I ran into an internal compiler error which I haven't seen
before.  One of the gcc options must have triggered something off.
Perhaps it was -Wwrite-strings, or maybe the -O2 (I normally use
-Os for a completely unrelated reason).  Either way, I need to find
out how to switch off those flags.  I'll also try to fix the compiler
internal error in i370.md.

BFN.  Paul.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> As such, it's appropriate to simply comment it out (which was my
> "workaround").  However, before I do so, do you think this is close
> to being correct?  I already made one correction, to put in that
> XL1 rather than doing a fullword (which was always zero obviously).
> 
> 
> (define_insn "movstrictqi"
>   [(set (strict_low_part (match_operand:QI 0 "nonimmediate_operand" "+d"))
>   (match_operand:QI 1 "general_operand" "g"))]
>   ""
>   "*
> {
>   check_label_emit ();
>   if (REG_P (operands[1]))
>     {
>       mvs_check_page (0, 8, 0);
>       return \"STC^I%1,\" CONVLO \"(,13)\;IC^I%0,\" CONVLO \"(,13)\";
>     }
>   mvs_check_page (0, 4, 0);
>   return \"IC^I%0,=XL1'%X1'\";
> }"
>    [(set_attr "length" "8")]
> )

The one obvious problem I see with this pattern is that the predicate
and constraint for operand 1 allow register, immediate and *memory*
operands, but the body seems to only handle register and immediate
operands correctly.

The STC followed by IC is of course correct, but will cause significant
penalities on all modern machines.  Just about any other way to load
the low byte (e.g. and with mask, then or) would be more efficient ...


> Which I can clearly see is different.  Specifically, the IC by itself is 
> fine,
> although I would have preferred to see the LA instruction there, but for
> some reason it is dropping the CLR.  That makes it technically
> incorrect.

This is odd.  I don't quite see why this would happen.  You should look
into the RTL dump files generated via -da to see where the compare insn
disappears ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

i370 port - constructing compile script

[Paul Edwards]

What is the best way to go from this:

Makefile:

C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o 
c-typeck.o \
  c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \

C_OBJS = c-lang.o stub-objc.o $(C_AND_OBJC_OBJS)

OBJS-common = \
^Iinsn-attrtab.o \
^Iinsn-automata.o \
^Iinsn-emit.o \
^Iinsn-extract.o \

to:

call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp builtins.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp caller-save.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp calls.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp c-aux-info.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp c-common.c %1 %2 %3 %4 %5 %6 %7 %8 %9

and then finally to:

//ALIAS    EXEC ST2CMP,MEMBER=ALIAS
//ALLOC@PO EXEC ST2CMP,MEMBER=ALLOC@PO
//ATTRIBS  EXEC ST2CMP,MEMBER=ATTRIBS
//BB@REORD EXEC ST2CMP,MEMBER=BB@REORD
//BITMAP   EXEC ST2CMP,MEMBER=BITMAP
//BT@LOAD  EXEC ST2CMP,MEMBER=BT@LOAD
//BUILTINS EXEC ST2CMP,MEMBER=BUILTINS
//CALLER@S EXEC ST2CMP,MEMBER=CALLER@S
//CALLS    EXEC ST2CMP,MEMBER=CALLS
//C@AUX@IN EXEC ST2CMP,MEMBER=C@AUX@IN
//C@COMMON EXEC ST2CMP,MEMBER=C@COMMON


I am happy to construct all of this on a Unix system with the various
tools (m4 etc) available.

But from the Unix system, I need to be able to generate the
above very simple compile script, which is a precursor to creating
very simple JCL steps (trust me, you don't want to see what
ST2CMP looks like).  Note that the JCL has the filenames
truncated to 8 characters, listed twice, uppercased, and '-'
and '_' converted to '@'.

I assume I need a C program to do such a conversion.  I'm happy
to write that C program.  But what's the best way to work with
the existing infrastructure when writing and running that C
program?

One idea I had was to have a target that listed all the variables,
and then just had an "echo" as the rule to make the ".o" from
".c", and then I could just go "make" to get all the object files
listed out, and then I run a separate C program to convert that
into the various scripts.

Note that the objective is to basically get a list (in the above
format) of all necessary C source in order to be able to compile
(to assembler, not .o) C programs.  I will be building a single
executable, ie combining the C front end and i370 back end
into a single executable.  I know that it is possible, because
I already have it working (on 3.4.6).  Now the objective is to do
it properly.  :-)

Also note that I'm not 100% sure what variables to use to get
the minimum required source, although I would guess
GCC_OBJS, C_OBJS plus the individual files listed in
ALL_HOST_OBJS.  This would be something that would be
good to have an explicit variable for - the minimum C files
required in the process of converting C to assembler (even
though in normal configurations, those C files reside in
different executables).  So I would like to define such a
variable prior to doing the above.

Thanks.  Paul.


P.S. Here are the (intrusive) changes I have had to make so far
to get (maybe 3/4 of) GCC 4.4 to compile on a C90-only platform:

Index: gcc/system.h
===================================================================
RCS file: /cvsroot/gcc4/gcc/system.h,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 system.h
180a181
> #ifdef HAVE_SYS_TYPES_H
181a183
> #endif
Index: include/sort.h
===================================================================
RCS file: /cvsroot/gcc4/include/sort.h,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 sort.h
24a25
> #ifdef HAVE_SYS_TYPES_H
25a27
> #endif
Index: libcpp/include/cpplib.h
===================================================================
RCS file: /cvsroot/gcc4/libcpp/include/cpplib.h,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 cpplib.h
26a27
> #ifdef HAVE_SYS_TYPES_H
27a29,30
> #endif
>
542,543c545,546
<   ino_t ino;
<   dev_t dev;
---
>   /* ino_t ino; */
>   /* dev_t dev; */
Index: libiberty/xmemdup.c
===================================================================
RCS file: /cvsroot/gcc4/libiberty/xmemdup.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 xmemdup.c
23a24
> #ifdef HAVE_SYS_TYPES_H
24a26
> #endif
Index: libiberty/xstrdup.c
===================================================================
RCS file: /cvsroot/gcc4/libiberty/xstrdup.c,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 xstrdup.c
18a19
> #ifdef HAVE_SYS_TYPES_H
19a21
> #endif

ie very little.

Not sure what the proper way to deal with that ino_t and dev_t is, but in
the past I've simply created my own typedefs:

typedef int ino_t;
typedef int dev_t;

and included them in config.h

But I'll deal with that after I've got a comprehensive list of source files.

Re: i370 port - constructing compile script

[Richard Henderson]

On 09/30/2009 08:00 AM, Paul Edwards wrote:
> What is the best way to go from this:
>
> Makefile:

The easy way to convert a Makefile to a shell script is "make -n".  That 
will print out all of the commands that make would run.  From there it's 
a Mere Matter of Programming to have perl (or whatever) edit that down 
into your JCL scripts.


r~

Re: i370 port - constructing compile script

[Paul Edwards]

>> What is the best way to go from this:
>>
>> Makefile:
>
> The easy way to convert a Makefile to a shell script is "make -n".  That 
> will print out all of the commands that make would run.  From there it's a 
> Mere Matter of Programming to have perl (or whatever) edit that down into 
> your JCL scripts.

Hi Richard.  Thanks for your reply.

1. That would include a lot of irrelevant commands - compiles and
links of the generator files interspersed with what I actually need
to go into the stage 1 executable on the target machine.

Maybe a variable STAGE1_OBJS would be suitable?

2. If the normal way to do things is to parse the make -n output
with perl etc, that's fine, I'll do it that way.  I was just wondering
if the proper way was to incorporate the logic into a Makefile
rule and get that rule repeatedly executed rather than just
having a simple "echo".  It seems to me that having a generic
rule to execute an external script would be neater???


BTW, I remember your name from the i370 md.  Why were you
interested in i370 at the time (probably many years ago)?  Or
was someone else just asking a public question and you
answered it (like now)?

BFN.  Paul.



  else
    {
        /* implementation suggested by  Richard Henderson <rth@cygnus.com> 
*/
        rtx reg1 = gen_reg_rtx (DImode);
        rtx reg2 = gen_reg_rtx (DImode);
        rtx result = operands[0];
        rtx mem1 = operands[1];
        rtx mem2 = operands[2];
        rtx len = operands[3];
        if (!CONSTANT_P (len))
          len = force_reg (SImode, len);

        /* Load up the address+length pairs.  */
        emit_insn (gen_rtx_CLOBBER (VOIDmode, reg1));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg1, 0),
                        force_operand (XEXP (mem1, 0), NULL_RTX));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg1, GET_MODE_SIZE 
(SImode)),

        emit_insn (gen_rtx_CLOBBER (VOIDmode, reg2));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg2, 0),
                        force_operand (XEXP (mem2, 0), NULL_RTX));
        emit_move_insn (gen_rtx_SUBREG (SImode, reg2, GET_MODE_SIZE 
(SImode)),

        /* Compare! */
        emit_insn (gen_cmpmemsi_1 (result, reg1, reg2));
    }
  DONE;
}")

Re: i370 port - constructing compile script

[Joseph S. Myers]

On Wed, 30 Sep 2009, Ian Lance Taylor wrote:

> "Paul Edwards" <mutazilah@gmail.com> writes:
> 
> > 2. If the normal way to do things is to parse the make -n output
> > with perl etc, that's fine, I'll do it that way.  I was just wondering
> > if the proper way was to incorporate the logic into a Makefile
> > rule and get that rule repeatedly executed rather than just
> > having a simple "echo".  It seems to me that having a generic
> > rule to execute an external script would be neater???
> 
> I'm not sure what you are suggesting here, but I do know that it
> wouldn't make sense for us to change the gcc Makefile to use a rule
> which executes an external script.
> 
> The "normal way to do things" is to use GNU make.  I think you are the
> first person trying to build gcc without it.

Not the first - BSDs have been known to import GCC sources into their 
repositories and write their own build system using BSD make.  No doubt 
this is a lot of work that needs repeating for each new version imported - 
that's the price you pay if you don't want to use the normal GCC build 
system.

(And GCC didn't always require GNU make - but the BSDs replacing the build 
system are a much closer analogy here than ordinary builds of old versions 
with other make implementations before GNU make was required.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: i370 port - constructing compile script

[Paul Edwards]

>> > 2. If the normal way to do things is to parse the make -n output
>> > with perl etc, that's fine, I'll do it that way.  I was just wondering
>> > if the proper way was to incorporate the logic into a Makefile
>> > rule and get that rule repeatedly executed rather than just
>> > having a simple "echo".  It seems to me that having a generic
>> > rule to execute an external script would be neater???
>>
>> I'm not sure what you are suggesting here, but I do know that it
>> wouldn't make sense for us to change the gcc Makefile to use a rule
>> which executes an external script.

I didn't mean use by default.

>> The "normal way to do things" is to use GNU make.  I think you are the
>> first person trying to build gcc without it.

It's also the first native MVS port.

Anyway, since then I had another idea.  I should be able to achieve
the same thing by just changing the C compiler to be "echo" or the
external script replacement.

Then all I need is a consolidated stage 1 target.

But today I spent my time fighting a different battle.

I tried to get configure to use my provided minimal (ie all of C90,
but no extensions) header files, using the --with-root option
and --with-build-root.

But it seemed to ignore those and use the ones on my Linux box,
insisting that sys/types existed etc.  Maybe I need to change my
INCLUDE_PATH or something instead.

> Not the first - BSDs have been known to import GCC sources into their
> repositories and write their own build system using BSD make.  No doubt
> this is a lot of work that needs repeating for each new version imported -
> that's the price you pay if you don't want to use the normal GCC build
> system.

> (And GCC didn't always require GNU make - but the BSDs replacing the build
> system are a much closer analogy here than ordinary builds of old versions
> with other make implementations before GNU make was required.)

Yeah, make isn't available (environment variables aren't available
in batch either), and even if it was, that's not what people want.  People
want SMP/E in fact.  But I don't know SMP/E.  I only know JCL, which
is the normal (and much much simpler) rival for SMP.

I don't think that doing a glorified "make -n" is a radical change to
the existing methodology.  Nor is a make target that just lists all
the stage 1 object files.  I think it would be a neat addition (even
if it remains a patch forever).

BFN.  Paul.

Re: i370 port - constructing compile script

[Paul Edwards]

I tried again but I'm not making much progress.

Maybe I need to go further than Canada, let's say Alaska.

1. First I need to use my current build machine, Linux,
to first of all convert the i370.md into insn*.c files, then
generate an xgcc.  The xgcc would be capable of producing
i370 code so long as I use the "-S" option.  It doesn't really
matter how this xgcc was created (ie using non-C90
stuff like fork available on my build machine).

2. It is now (at the Alaskan stage) that I need a different sort
of config.h/auto-host.h that excludes things like fork.  I can
present my i370 include files here, that only include C90
functions.  It is at this stage that I need it to invoke xgcc
(still on the build machine), but it will be with the -S option,
so there will be no .o files (although I could perhaps fake
that via a scipt to keep "make" happy) and no executable
built.  The "fake" script could generate JCL at the same time.
The C90 library (for MVS) also needs to be cross-compiled
here.

3. Then I need to assemble all the assembler on real i370
(MVS).  It is at this point that a real host (ie on i370 MVS)
xgcc is built.

4. Then I can use that xgcc (on MVS) to compile arbitary
C programs.  Technically I could have had a requirement
for this i370-mvs host compiler to produce say sparc target
code.

All of the above ignores the bootstrap on MVS, which I know
is easy to add on later.

To fit into the standard Canadian Cross 3-step model, I need
to either collapse steps 2 and 3 into 1 theoretical step, executed
across 2 platforms (compile on one, assemble on another), or I
need to omit step 4, and say that I cannot target any platform
other than the host.  Which is fine by me anyway.  If combining
steps 2 and 3, we could ignore the fact that step 3 happens at
all, and assume that there is a theoretical machine that directly
executes assembler code.

I suspect that it will only take 20 lines or similar of intrusive
Makefile/shell script changes to shoe-horn my way into the
existing gcc methodology.  All I need to do is force it to use
my C90 headers at the right spot, so that it stops thinking
that I have fork etc, and stop it trying to build an executable.

Can someone tell me where to put those 20 lines?  I have been
playing around with something like this:

./configure --host=i370-mvspdp --enable-languages=c --with-local-prefix=/devel/pdos/pdpclib

but haven't been getting very far.

I have one more option, and in fact, maybe it's even a preference.

The C90-only library (PDPCLIB) I have on MVS is also on Linux,
and gives me advance warning of problems about to happen on
MVS.  As such, I could force the build machine to use this C90 library
to build the first xgcc.  Then the config file etc would be correct
for the next step.  Mostly correct, anyway.  It would probably get
the stack direction wrong instead of leaving it unknown.

What suggestions for a configure command that would come
closest to what I want?  Note that with the above host I had to
copy "ar" to "i370-mvspdp-ar" to get it to the stage of building
the xgcc.

Note - prior to this latest exercise, in order to get some initial
feedback, I had been manually constructing the auto-host
and using my manually-created compile script to compile.
But that's a pretty horrible life, when I'm pretty sure that a
judiciously-placed 20 lines of code and some nifty config
parameters for host and target will automate the thing.

Any suggestions that don't involve "forget about MVS - no-one
even knows how to spell MVS these days"?

Thanks.  Paul.

Re: i370 port - constructing compile script

[Ian Lance Taylor]

"Paul Edwards" <mutazilah@gmail.com> writes:

> 1. First I need to use my current build machine, Linux,
> to first of all convert the i370.md into insn*.c files, then
> generate an xgcc.  The xgcc would be capable of producing
> i370 code so long as I use the "-S" option.  It doesn't really
> matter how this xgcc was created (ie using non-C90
> stuff like fork available on my build machine).
>
> 2. It is now (at the Alaskan stage) that I need a different sort
> of config.h/auto-host.h that excludes things like fork.  I can
> present my i370 include files here, that only include C90
> functions.  It is at this stage that I need it to invoke xgcc
> (still on the build machine), but it will be with the -S option,
> so there will be no .o files (although I could perhaps fake
> that via a scipt to keep "make" happy) and no executable
> built.  The "fake" script could generate JCL at the same time.
> The C90 library (for MVS) also needs to be cross-compiled
> here.
>
> 3. Then I need to assemble all the assembler on real i370
> (MVS).  It is at this point that a real host (ie on i370 MVS)
> xgcc is built.
>
> 4. Then I can use that xgcc (on MVS) to compile arbitary
> C programs.  Technically I could have had a requirement
> for this i370-mvs host compiler to produce say sparc target
> code.

What most people do is:

* Configure gcc as a cross-compiler.
* Write a cross-assembler and cross-linker.
* Copy header files and libraries from the host (MVS).

Now you have a complete cross-toolchain running on a supported host
which can produce executables which run on MVS.

* Use that cross-toolchain to build a version of gcc which runs on
  MVS.  At this step you port gcc to work on MVS.
* Run that gcc on MVS.

(Note that you mention fork, but as you probably know the gcc code
never actually calls fork.  It calls the pexecute routines in
libiberty.  Those routines have been ported to several different
hosts, including MS-DOS.  If you port them to MVS, then you don't have
to worry about fork.)


> To fit into the standard Canadian Cross 3-step model, I need
> to either collapse steps 2 and 3 into 1 theoretical step, executed
> across 2 platforms (compile on one, assemble on another),

Right, people normally do this by using a cross-assembler and
cross-linker.


> I suspect that it will only take 20 lines or similar of intrusive
> Makefile/shell script changes to shoe-horn my way into the
> existing gcc methodology.  All I need to do is force it to use
> my C90 headers at the right spot, so that it stops thinking
> that I have fork etc, and stop it trying to build an executable.
>
> Can someone tell me where to put those 20 lines?

One way to shoe-horn those lines in would be to make your
cross-assembler and cross-linker actually be shell scripts.  They
would copy the files to MVS, run the real assembler and linker, and
copy the output back.  That would be more than 20 lines, but it seems
doable to me.

But I don't understand the bit about C90 headers.  gcc doesn't need
fork, but it does need a way to execute other programs.

Ian

Re: i370 port - constructing compile script

[Paul Edwards]

Hi Ian, thanks for your reply.

>> 1. First I need to use my current build machine, Linux,
>> to first of all convert the i370.md into insn*.c files, then
>> generate an xgcc.  The xgcc would be capable of producing
>> i370 code so long as I use the "-S" option.  It doesn't really
>> matter how this xgcc was created (ie using non-C90
>> stuff like fork available on my build machine).
>>
>> 2. It is now (at the Alaskan stage) that I need a different sort
>> of config.h/auto-host.h that excludes things like fork.  I can
>> present my i370 include files here, that only include C90
>> functions.  It is at this stage that I need it to invoke xgcc
>> (still on the build machine), but it will be with the -S option,
>> so there will be no .o files (although I could perhaps fake
>> that via a scipt to keep "make" happy) and no executable
>> built.  The "fake" script could generate JCL at the same time.
>> The C90 library (for MVS) also needs to be cross-compiled
>> here.
>>
>> 3. Then I need to assemble all the assembler on real i370
>> (MVS).  It is at this point that a real host (ie on i370 MVS)
>> xgcc is built.
>>
>> 4. Then I can use that xgcc (on MVS) to compile arbitary
>> C programs.  Technically I could have had a requirement
>> for this i370-mvs host compiler to produce say sparc target
>> code.
>
> What most people do is:
>
> * Configure gcc as a cross-compiler.

So this would not be considered a Canadian Cross after all,
and with configure I only change the target, not the host?

> * Write a cross-assembler and cross-linker.

Sure, and that's what I'm trying to avoid.  I have a perfectly working
assembler and linker on MVS already.  It's been working for several
decades.

> * Copy header files and libraries from the host (MVS).

That's fine.  And use the --with-root option of configure to get
them used?

> Now you have a complete cross-toolchain running on a supported host
> which can produce executables which run on MVS.

It's a can of worms just trying to copy MVS load modules.  There's
meta-data in 2 different places and it needs to be packaged.

> * Use that cross-toolchain to build a version of gcc which runs on
>  MVS.  At this step you port gcc to work on MVS.
> * Run that gcc on MVS.
>
> (Note that you mention fork, but as you probably know the gcc code
> never actually calls fork.  It calls the pexecute routines in
> libiberty.  Those routines have been ported to several different
> hosts, including MS-DOS.  If you port them to MVS, then you don't have
> to worry about fork.)

I spent several minutes going through the config.h looking at the
"detected" functions to find a good example.  Maybe I should I
have getrlimit or getrusage or fputs_unlocked instead.

>> To fit into the standard Canadian Cross 3-step model, I need
>> to either collapse steps 2 and 3 into 1 theoretical step, executed
>> across 2 platforms (compile on one, assemble on another),
>
> Right, people normally do this by using a cross-assembler and
> cross-linker.

Ok.

>> I suspect that it will only take 20 lines or similar of intrusive
>> Makefile/shell script changes to shoe-horn my way into the
>> existing gcc methodology.  All I need to do is force it to use
>> my C90 headers at the right spot, so that it stops thinking
>> that I have fork etc, and stop it trying to build an executable.
>>
>> Can someone tell me where to put those 20 lines?
>
> One way to shoe-horn those lines in would be to make your
> cross-assembler and cross-linker actually be shell scripts.

Ok, that's no problem.

> They
> would copy the files to MVS, run the real assembler and linker, and
> copy the output back.

I might theoretically be able to do such a thing, but that's not what I'm
after.  I'm just after 200+ assembler files to be produced so that I can
zip them up and take them to a real MVS site or whatever to get
compiled.  It looks like someone just wrote a C compiler in
370 assembler, which is now all natural MVS (the objective of the
exercise).

> That would be more than 20 lines, but it seems
> doable to me.

Actually, that would be 0 lines of intrusive code (ie changing GCC
itself).

> But I don't understand the bit about C90 headers.  gcc doesn't need
> fork, but it does need a way to execute other programs.

No, I use intrusive code to convert the pexecute call into a static
call to cc1 (effectively - I actually intercept it within gcc itself, see
below).  And that is why I need a Makefile target that includes
all the object code.  Because I compile the 450,000 lines of C code
into 850,000 lines of assembler code to produce a 3.4 MB gcc load
module for MVS.  Those figures are from gcc 3.4.6.

BFN.  Paul.




***************
*** 2610,2615 ****
--- 2623,2631 ----
  static int
  execute (void)
  {
+ #ifdef SINGLE_EXECUTABLE
+   int ret_code = 0;
+ #endif
    int i;
    int n_commands;             /* # of command.  */
    char *string;
***************
*** 2756,2761 ****
--- 2772,2792 ----
        char *errmsg_fmt, *errmsg_arg;
        const char *string = commands[i].argv[0];

+ #ifdef SINGLE_EXECUTABLE
+      {
+          int cnt = 0;
+
+          while (commands[i].argv[cnt] != NULL)
+          {
+              cnt++;
+          }
+          if (strcmp(string, "cc1") == 0)
+          {
+              ret_code = toplev_main(cnt, commands[i].argv);
+              if (ret_code != 0) break;
+          }
+       }
+ #else
        /* For some bizarre reason, the second argument of execvp() is
         char *const *, not const char *const *.  */
        commands[i].pid = pexecute (string, (char *const *) 
commands[i].argv,

Re: i370 port - constructing compile script

[Ian Lance Taylor]

"Paul Edwards" <mutazilah@gmail.com> writes:

>> * Configure gcc as a cross-compiler.
>
> So this would not be considered a Canadian Cross after all,
> and with configure I only change the target, not the host?

The end result is a Canadian Cross, but the first step in a typical
build of a Canadian Cross is a cross-compiler.


>> * Write a cross-assembler and cross-linker.
>
> Sure, and that's what I'm trying to avoid.  I have a perfectly working
> assembler and linker on MVS already.  It's been working for several
> decades.

There are many advantages of a cross-assembler and cross-linker, but,
whatever.


>> * Copy header files and libraries from the host (MVS).
>
> That's fine.  And use the --with-root option of configure to get
> them used?

--with-sysroot, yes.


>> (Note that you mention fork, but as you probably know the gcc code
>> never actually calls fork.  It calls the pexecute routines in
>> libiberty.  Those routines have been ported to several different
>> hosts, including MS-DOS.  If you port them to MVS, then you don't have
>> to worry about fork.)
>
> I spent several minutes going through the config.h looking at the
> "detected" functions to find a good example.  Maybe I should I
> have getrlimit or getrusage or fputs_unlocked instead.

fputs_unlocked is only used for systems which provide it.  On systems
which don't, gcc uses fputs.

Similarly, getrlimit and getrusage are entirely optional.  They are
used if available, otherwise not.


I've been discussing this under the assumption that you want to
contribute your port back to gcc.  If you don't, then I think I will
step out.  You can pursue whatever path you like.

Ian

Re: i370 port - constructing compile script

[Paul Edwards]

>>> * Configure gcc as a cross-compiler.
>>
>> So this would not be considered a Canadian Cross after all,
>> and with configure I only change the target, not the host?
> 
> The end result is a Canadian Cross, but the first step in a typical
> build of a Canadian Cross is a cross-compiler.

Ok.

>>> * Write a cross-assembler and cross-linker.
>>
>> Sure, and that's what I'm trying to avoid.  I have a perfectly working
>> assembler and linker on MVS already.  It's been working for several
>> decades.
> 
> There are many advantages of a cross-assembler and cross-linker, but,
> whatever.

One of them is not "you can leverage into all the existing work
of the existing-and-working-fine IFOX00 and IEWL".

>>> * Copy header files and libraries from the host (MVS).
>>
>> That's fine.  And use the --with-root option of configure to get
>> them used?
> 
> --with-sysroot, yes.

I have been trying combinations of --prefix and --with-sysroot, 
and --with-build-sysroot, but it is still insisting that I have an 
fputs_unlocked etc, despite pointing all those things to a
directory that has no such thing in it, and just has my C90
headers.

>>> (Note that you mention fork, but as you probably know the gcc code
>>> never actually calls fork.  It calls the pexecute routines in
>>> libiberty.  Those routines have been ported to several different
>>> hosts, including MS-DOS.  If you port them to MVS, then you don't have
>>> to worry about fork.)
>>
>> I spent several minutes going through the config.h looking at the
>> "detected" functions to find a good example.  Maybe I should I
>> have getrlimit or getrusage or fputs_unlocked instead.
> 
> fputs_unlocked is only used for systems which provide it.  On systems
> which don't, gcc uses fputs.
>
> Similarly, getrlimit and getrusage are entirely optional.  They are
> used if available, otherwise not.

Right.  I'm having trouble getting it to ignore the ones that are installed
on the build system, and to switch to the directory given with
--with-sysroot.  Also, for the long term, it would be better to
distinguish the headers that I use on the build system, to the
headers used when cross-compiling.  As I mentioned, I happen
to be in a position where I can use the same ones on MVS, on
Linux (and some other platforms too), so I can get away with
forcing it to the C90 headers immediately.

> I've been discussing this under the assumption that you want to
> contribute your port back to gcc.  If you don't, then I think I will
> step out.  You can pursue whatever path you like.

I do want it to be in the mainline gcc.  But the requirements for
reversing the 2004 deletion of the i370 target (which can be done
with two svn commands) are too onerous to be met for likely
years.  I personally think it's strange that we had an i370 target 
that didn't meet those requirements from 1993 to 2004, but now 
it isn't, regardless of the fact that it now works better than ever 
before (not suprising after more than 5 years of effort by multiple
people).  But there's not much I can do about that.

Way back In 1998 I was talking to someone from GCC (not ecgs)
about getting some mods in to support MVS (I wasn't aware of
other MVS activity on the ecgs side).  The computer with the 
conversation was stolen, so I don't know who that was.  Whoever
it was, I think they had plans to rewrite the i370.md themselves
(but that obviously didn't happen).  My changes were all outside that.

Basically I needed those small mods to create a single executable
plus some other minor mods (similar to what I posted here recently).
I don't recall if any of it was accepted or not (I just gave the patches,
and no longer have those to see if they got in).  I know the 
single-executable mods didn't get in, because I know what to
look for, and it isn't there.

There's not much I can do about the non-acceptance of the mods,
but the one thing I can do is keep my modification footprint low.
That's why I believe that 20 lines somewhere in the configuration
scripts are probably enough to get what I want, without upsetting
the existing structure.  Maybe eventually those 20 lines will be
accepted as a non-default option, but that is beyond my control.

But regardless of whether it is accepted or not, I want to be able
to demonstrate it working first.

Where "working" doesn't mean "write my own cross-assembler 
and cross-linker and change MVS to be posix instead of MVS
and get the entire test suite working", but rather "work the same
way that gccmvs 3.2.3 works (ie bootstrapping works), except 
get the JCL and auto-host to be automatically generated instead
of manually constructed for each release".

It takes several days of effort to manually construct those files 
and debug the problems with them, when I suspect that with the 
right config command-line and a little bit of intrusive code, plus
some external support scripts (that are no skin off anyone's
nose), the whole thing can be automated.

Anyway, I'll keep plugging away.  I resorted to renaming
/usr/include, but that triggered off other problems.  I suspect it
will come down to one line of code or one extra configure
parameter, but it'll probably take days of experimentation
to find that.

BFN.  Paul.

Re: i370 port - constructing compile script

[Ian Lance Taylor]

"Paul Edwards" <mutazilah@gmail.com> writes:

>>>> * Copy header files and libraries from the host (MVS).
>>>
>>> That's fine.  And use the --with-root option of configure to get
>>> them used?
>>
>> --with-sysroot, yes.
>
> I have been trying combinations of --prefix and --with-sysroot, and
> --with-build-sysroot, but it is still insisting that I have an
> fputs_unlocked etc, despite pointing all those things to a
> directory that has no such thing in it, and just has my C90
> headers.

The --with-sysroot option tells gcc where to find header files and
libraries for the target.  The --with-build-sysroot option tells gcc
where to find header files and libraries for the target while building
gcc itself.  fputs_unlocked is called by gcc itself, not by target
code; therefore, what matters for whether fputs_unlocked is supported
is the host header files and libraries, not the target header files
and libraries.  So using --with-sysroot is never going to affect
whether gcc itself uses fputs_unlocked.

The case where that should work if you configure gcc using
--with-sysroot to point to C90 headers and libraries, and you use that
gcc to build another gcc.  That is, configure gcc as a cross-compiler
to a system which happens to be very similar to the host system, and
then use that cross-compiler to build a new compiler, in what is
effectively a same-system Canadian Cross.  The second gcc should not
use fputs_unlocked in that case.


>> Similarly, getrlimit and getrusage are entirely optional.  They are
>> used if available, otherwise not.
>
> Right.  I'm having trouble getting it to ignore the ones that are installed
> on the build system, and to switch to the directory given with
> --with-sysroot.

When talking about this kind of thing, you have to distinguish the
build system and the host system.  The header files on the build
system are irrelevant.  The header files on the host system are what
matter.  Normally the build system and the host system are the same,
but this is not true when building with a cross-compiler.

> Also, for the long term, it would be better to
> distinguish the headers that I use on the build system, to the
> headers used when cross-compiling.  As I mentioned, I happen
> to be in a position where I can use the same ones on MVS, on
> Linux (and some other platforms too), so I can get away with
> forcing it to the C90 headers immediately.

gcc has no confusion between the headers on the host system and the
headers on the target system.  I don't know precisely how to map that
onto your comment about the build system and the headers used when
cross-compiling.


> There's not much I can do about the non-acceptance of the mods,
> but the one thing I can do is keep my modification footprint low.
> That's why I believe that 20 lines somewhere in the configuration
> scripts are probably enough to get what I want, without upsetting
> the existing structure.  Maybe eventually those 20 lines will be
> accepted as a non-default option, but that is beyond my control.

If you can demonstrate that 20 line configure script change, then we
can certainly discuss it.  I personally am rather skeptical that you
can rewire gcc's build process in 20 lines.

Ian

Re: i370 port - constructing compile script

[Paul Edwards]

>>>>> * Copy header files and libraries from the host (MVS).
>>>>
>>>> That's fine.  And use the --with-root option of configure to get
>>>> them used?
>>>
>>> --with-sysroot, yes.
>>
>> I have been trying combinations of --prefix and --with-sysroot, and
>> --with-build-sysroot, but it is still insisting that I have an
>> fputs_unlocked etc, despite pointing all those things to a
>> directory that has no such thing in it, and just has my C90
>> headers.
>
> The --with-sysroot option tells gcc where to find header files and
> libraries for the target.  The --with-build-sysroot option tells gcc
> where to find header files and libraries for the target while building
> gcc itself.

But that's the first step in what I'm doing, isn't it?

> fputs_unlocked is called by gcc itself, not by target code;

As such, I am in a position where I can point it to my C90 libraries.

I have everything I need to create the xgcc as a single executable
on Linux that produces i370 assembler.  That's what I already have
with gcc 3.4.6.

With 3.4.6, I have a script called "compile", which looks like this:

call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcomp bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9
...
gcc -s -nostdlib -o gccmvs.exe *.o ../../pdos/pdpclib/pdpwin32.a -lkernel32

The Windows version is simpler, but I have the equivalent for Linux.

I call it gccmvs instead of xgcc.

That's my cross-compiler.

That was sort of hand-constructed (I actually selected stuff from
the output of a normal make on Linux, skipping stuff that was
used to produce the generator files (genrecog etc).

I believe that a simple script like above can be *generated* with a
few lines of changes to an appropriate makefile.  That's why I
mentioned before that I'm after a makefile target that only lists
the object code that would go into a stage 1 executable.

> therefore, what matters for whether fputs_unlocked is supported
> is the host header files and libraries, not the target header files
> and libraries.  So using --with-sysroot is never going to affect
> whether gcc itself uses fputs_unlocked.

Well even with --with-build-sysroot I don't seem to be able to
steer it away from my system's header files.  But this is a
more minor aspect to what I'm interested in.  I think I'll just
rename my system header files and copy in the C90
headers.

> The case where that should work if you configure gcc using
> --with-sysroot to point to C90 headers and libraries, and you use that
> gcc to build another gcc.  That is, configure gcc as a cross-compiler
> to a system which happens to be very similar to the host system, and
> then use that cross-compiler to build a new compiler, in what is
> effectively a same-system Canadian Cross.  The second gcc should not
> use fputs_unlocked in that case.

This comment has me confused.

I already have gcc 4.4 installed as a native compiler.  I am now
trying to build on Linux, to produce a Linux-to-i370 cross-compiler.

Therefore the first thing I want to do is build a cross-compiler,
right?  Or does the build process want to force me to compile
gcc 4.4 as a native compiler *again*?  I was expecting it to just
use what I already have, which coincidentally happens to be
gcc 4.4.  Can I skip that step then?  I (used to) sometimes use
a different compiler, such as Watcom or Borland, on Windows,
in order to build the windows-to-i370 cross.

>>> Similarly, getrlimit and getrusage are entirely optional.  They are
>>> used if available, otherwise not.
>>
>> Right.  I'm having trouble getting it to ignore the ones that are 
>> installed
>> on the build system, and to switch to the directory given with
>> --with-sysroot.
>
> When talking about this kind of thing, you have to distinguish the
> build system and the host system.  The header files on the build
> system are irrelevant.  The header files on the host system are what
> matter.  Normally the build system and the host system are the same,
> but this is not true when building with a cross-compiler.

In my case, I intend to run the cross-compiler on Linux to make sure
it works.  On Linux I also want to generate the compile script, and
to generate the JCL.

Once I have all those things (on the best system for gcc tools), I
then want to package it all up and move to Windows.

There I will run the compile script (shown above), and make sure that
it also produces a single executable.  I will use gcc 3.4.4 for that task,
because it comes by default with Cygwin.  I may choose to use
Borland etc instead, but unlikely.

At this stage I will be confident that I have a single C90-compliant
executable, and the challenge becomes whether I can reproduce
that on MVS.

So I run a slightly different script, compmvs, which looks like this:

call stdcompm alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm builtins.c %1 %2 %3 %4 %5 %6 %7 %8 %9
call stdcompm caller-save.c %1 %2 %3 %4 %5 %6 %7 %8 %9

stdcompm.bat:
gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CONFIG_H -DIN_GCC 
...

Once I have the assembler code, I zip it up, then use my Linux-generated
JCL and pass it all over to MVS to see if it can assemble a stage 1
executable, which is how I have a 3.4.6 MVS executable.

>> Also, for the long term, it would be better to
>> distinguish the headers that I use on the build system, to the
>> headers used when cross-compiling.  As I mentioned, I happen
>> to be in a position where I can use the same ones on MVS, on
>> Linux (and some other platforms too), so I can get away with
>> forcing it to the C90 headers immediately.
>
> gcc has no confusion between the headers on the host system and the
> headers on the target system.  I don't know precisely how to map that
> onto your comment about the build system and the headers used when
> cross-compiling.

Ok, I'm lost even further up the process now.

I'm not sure whether to call MVS a target or host.

>> There's not much I can do about the non-acceptance of the mods,
>> but the one thing I can do is keep my modification footprint low.
>> That's why I believe that 20 lines somewhere in the configuration
>> scripts are probably enough to get what I want, without upsetting
>> the existing structure.  Maybe eventually those 20 lines will be
>> accepted as a non-default option, but that is beyond my control.
>
> If you can demonstrate that 20 line configure script change, then we
> can certainly discuss it.  I personally am rather skeptical that you
> can rewire gcc's build process in 20 lines.

It's about 20 lines of intrusive code to combine GCC into a single
executable, bypassing the need for a system() or similar call.

Why would this be any different?

The gcc build process *already* compiles each module.

All I need to do is restrict the list of modules, and add the "-S"
option, and then tell it to not complain about the ".o" not being
generated, because I produced a ".s" instead.

Doesn't sound like a lot of work if I can figure out where to put
it, and the "-S" and a touch of ".o" can go into an external
script to even eliminate that intrusion!  :-)

BFN.  Paul.

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> I'm not sure whether to call MVS a target or host.

Maybe it helps to take a step back and look at how the process
of initially getting a compiler for a system B built, starting
on an existing system A, usually works.

Each of the following steps can be identified by three systems:
- the "build" system (where the compiler build process runs)
- the "host" system (where the resulting compiler will run)
- the "target" system (where executables built by that compiler run)

Using this terminology, we need the following four stages:
(In your case, A would be "Linux on Intel", and B would be "MVS".)

1. build == A, host == A, target == A

This is the compiler you start out with, a native compiler for the A
system.  (You already have that, you do not need to rebuild it.)

2. build == A, host == A, target == B

This is a cross-compiler for B, running on A, which is itself built
on A using the compiler from 1.

3. build == A, host == B, target == B

This is a native B compiler, but it is *built* on A, using the A->B
cross-compiler from 2.  (This way of building a compiler is sometimes
refered to as a "Canadian cross".)

4. build == B, host == B, target == B

This step is optional, but using the native B compiler from 3., you
could now rebuild the compiler once again, this time on B itself.
At this point, B is fully supported and able to bootstrap its compiler
without any assistance from another system.


As there is nothing to do for step 1, and step 4 is optional, the
interesting parts are steps 2 and 3.  These are two separate build steps,
targeting different host systems to run the resulting compiler on.

As the properties of the host system (e.g. does it have "fork"
or "getrusage" or whatever) are detected at build time during
the "configure" step, you need to have a separate configure run
for step 2 and step 3.  Note that configure works but attempting
to compile and/or link small test programs.

In step 2, configure will use the host A compiler (from step 1) to
do these trial compiles.  The host A compiler will use the host A
header files and libaries, and thus configure will detect properties
of system A (which is correct, as in step 2, "host" == A).

In step 3, configure will use the A->B cross-compiler (from step 2)
to do the trial compiles.  This compiler, if built correctly, will
use host *B* header files and libraries from its sysroot, and thus
configure will detect properties of system *B* (which again is correct,
as in step 3, "host" == B).


From the symptoms you describe, it would appear that you're picking
up bad configure results in step 3.  Depending on what exactly you
do, this might be either because you don't actually re-run configure
but attempt to use the configure results from step 2 (that certainly
cannot work), or else your step 2 cross-compiler was itself built
incorrectly in some form so it doesn't properly pick up headers
from its sysroot, or else the headers in the sysroot are simply
incorrect ...  You should investigate the various log files left by
configure to figure out what's going on.

Note that one problem might be that your step 2 cross-compiler
cannot actually link executables as it is missing the cross-linker
required to do so.  I *think* the core GCC (C-only) configure
process should be able to handle this, but I might be mistaken
here.


I'm not sure if this helps, but I hope this might have at least
clarified a bit some of the terminology being used ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

> In step 3, configure will use the A->B cross-compiler (from step 2)
> to do the trial compiles.  This compiler, if built correctly, will
> use host *B* header files and libraries from its sysroot, and thus
> configure will detect properties of system *B* (which again is correct,
> as in step 3, "host" == B).
> 
> From the symptoms you describe, it would appear that you're picking
> up bad configure results in step 3.  Depending on what exactly you
> do, this might be either because you don't actually re-run configure
> but attempt to use the configure results from step 2 (that certainly
> cannot work), or else your step 2 cross-compiler was itself built
> incorrectly in some form so it doesn't properly pick up headers
> from its sysroot, or else the headers in the sysroot are simply
> incorrect ...  You should investigate the various log files left by
> configure to figure out what's going on.

Thanks for the explanation Ulrich.

I was previously under the impression (my interpretation of the
documentation) that I just needed to do one configure, and it 
would do both of the steps you mentioned.

> Note that one problem might be that your step 2 cross-compiler
> cannot actually link executables as it is missing the cross-linker
> required to do so.  I *think* the core GCC (C-only) configure
> process should be able to handle this, but I might be mistaken
> here.

Would you be able to give me the two suggested configure
commands so that I can find out the answer to the above, one
way or another?

Perhaps if that bit fails I will need to replace the cross-compiler
and cross-linker with normal gcc during the configure process,
and only give it access to some C90 libraries.  It so happens
that I have a full suite of those, but even if I didn't, I could
create a dummy printf etc so that it would at least link.

Or does the configure process attempt to run the executables
as well?

No mind - as I said, I have the full suite for a configure to work.

But it won't be able to correctly determine the stack direction
if it does that.  So that is the sort of thing I would need some
intrusive code (out of my 20 lines quota!) to force it to 0
(unknown stack direction).

Thanks.  Paul.

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> Would you be able to give me the two suggested configure
> commands so that I can find out the answer to the above, one
> way or another?

For step 2 (building the cross-compiler), you'd need something
along the lines of

 .../configure --target=i370-mvs --prefix=... --with-sysroot=...  \
               --enable-languages=c

where prefix points to the directory where the cross-compiler
should be installed, and sysroot points to the directory where
the MVS libraries and header are installed.

Then you need to build and install the cross-compiler (using
make and make install).   For the subsequent step, you need to
make the cross-compiler available in the PATH.

For step 3 (cross-building a native compiler), you'd need
something along the lines of

  .../configure --build=i686-linux --host=i370-mvs --target=i370-mvs \
                --prefix=... --with-build-sysroot=... --enable-languages=c

This configure run will then use the i370-mvs-gcc cross-compiler
you built in step 2 in order to detect MVS host properties.

> Or does the configure process attempt to run the executables
> as well?

No, that wouldn't work (the exectuables are for a different architecture
than the build system ...).

> But it won't be able to correctly determine the stack direction
> if it does that.  So that is the sort of thing I would need some
> intrusive code (out of my 20 lines quota!) to force it to 0
> (unknown stack direction).

I don't think GCC needs to know the stack direction of the *host*
system.  (It does need to know the stack direction of the *target*
system, but this is not detected by configure, but determined by
target macro settings from the config/i370/*.h files.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

>> Would you be able to give me the two suggested configure
>> commands so that I can find out the answer to the above, one
>> way or another?
> 
> For step 2 (building the cross-compiler), you'd need something
> along the lines of
> 
> .../configure --target=i370-mvs --prefix=... --with-sysroot=...  \
>               --enable-languages=c
> 
> where prefix points to the directory where the cross-compiler
> should be installed, and sysroot points to the directory where
> the MVS libraries and header are installed.

I tried to action this today.

But first I tried to get the normal make process working, ie without
the --prefix and --with-sysroot above, and just using defaults.  I had
some surprising success, but also one failure.

The failure (on 3.4.6, but not on 3.2.3) is that after the successful
build, when I do an xgcc -S, it produces the assembler file, and then 
hangs.  I traced this to gcc.c which was in a loop doing this:

pid = pwait (commands[i].pid, &status, 0);

getting a return of 0 all the time, while the process (cc1) that it is
waiting on is showing up as being <defunct>.

Not sure what that is about.  I have gcc 3.2.3 working without that
problem, so I'll spend some time comparing how the two pexecutes
work differently.

Of course I don't have system-related problems like this on MVS,
because I have a single executable and a simple function call.  :-)

In the meantime, I have a question.  You said above that I have to
point sysroot to the MVS libraries and headers.  What libraries?
And why, at the point of building a cross-compiler, do I need any
of those things?  The normal way I build a cross-compiler I just
do the above configure without prefix or with-sysroot, and it
builds an xgcc executable as expected, using the Linux headers,
as expected.

I would certainly like an option to force it to use my C90-only
Linux headers and my C90-only libraries, but that should be
strictly optional, and if I did do that, I would expect to see
configure saying things like "no you don't have fork, or getrusage,
or sys/types" etc etc.

I think I am still failing to understand some major aspect of the
build process.

BFN.  Paul.

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards:

> The failure (on 3.4.6, but not on 3.2.3) is that after the successful
> build, when I do an xgcc -S, it produces the assembler file, and then 
> hangs.  I traced this to gcc.c which was in a loop doing this:
> 
> pid = pwait (commands[i].pid, &status, 0);
> 
> getting a return of 0 all the time, while the process (cc1) that it is
> waiting on is showing up as being <defunct>.
> 
> Not sure what that is about.  I have gcc 3.2.3 working without that
> problem, so I'll spend some time comparing how the two pexecutes
> work differently.

Huh.  I've never seen this before.  Is this with your patches to
generate a "single executable" or without?  For the cross-compiler,
you shouldn't need any of the MVS host-specific patches ...

> In the meantime, I have a question.  You said above that I have to
> point sysroot to the MVS libraries and headers.  What libraries?
> And why, at the point of building a cross-compiler, do I need any
> of those things?  The normal way I build a cross-compiler I just
> do the above configure without prefix or with-sysroot, and it
> builds an xgcc executable as expected, using the Linux headers,
> as expected.
> 
> I would certainly like an option to force it to use my C90-only
> Linux headers and my C90-only libraries, but that should be
> strictly optional, and if I did do that, I would expect to see
> configure saying things like "no you don't have fork, or getrusage,
> or sys/types" etc etc.
> 
> I think I am still failing to understand some major aspect of the
> build process.

Maybe the confusion is about what "sysroot" for a cross-compiler
means.  The libraries and headers in the sysroot are *not* used
to build the compiler itself.  You need to specify the sysroot
location at build time of the compiler only so that this location
can be compiled into the gcc/cc1 binaries.  Once you later *use*
the resulting cross-compiler, this cross-compiler will refer to
the sysroot location for standard headers and libraries.

That is to say, if you build a cross-compiler with
    --prefix=/home/gccmvs/cross
    --sysroot=/home/gccmvs/sysroot
    --target=i370-mvs
the result of the build process ("make" and then "make install")
will be a cross-compiler in /home/gccmvs/cross/bin/i370-mvs-gcc
(and additional files in /home/gccmvs/cross/lib/gcc/...).

Note that the build process of the compiler itself will refer to
the host's default headers in /usr/include and libraries in
/usr/lib.

However, once you *run* this i370-mvs-gcc, and it processes a source
file using #include <stdio.h>, the compiler will search the directory
/home/gccmvs/sysroot/include for the stdio.h header file, and it will
invoke the cross-linker passing /home/gccmvs/sysroot/lib as the 
location to search for standard libraries like libc.  (Note that the
names of such standard libraries, if any, are defined by the MVS
target definitions, in particular the setting of target macros like
LIB_SPEC in your target header files in config/i370/*.h.)


It is important to get this cross-compiler working correctly, i.e.
refering to the proper headers and libraries, because in the next
step, when you configure and build the native compiler, you'll be
using the cross-compiler, and what headers it uses will determine
which host features are detected by configure ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

>> The failure (on 3.4.6, but not on 3.2.3) is that after the successful
>> build, when I do an xgcc -S, it produces the assembler file, and then 
>> hangs.  I traced this to gcc.c which was in a loop doing this:
>> 
>> pid = pwait (commands[i].pid, &status, 0);
>> 
>> getting a return of 0 all the time, while the process (cc1) that it is
>> waiting on is showing up as being <defunct>.
>> 
>> Not sure what that is about.  I have gcc 3.2.3 working without that
>> problem, so I'll spend some time comparing how the two pexecutes
>> work differently.
> 
> Huh.  I've never seen this before.  Is this with your patches to
> generate a "single executable" or without?

My patches are applied, but shouldn't be activated, because
I haven't defined SINGLE_EXECUTABLE.

I could try taking it back to raw 3.4.6 though and see if that has
the same problem.

> For the cross-compiler,
> you shouldn't need any of the MVS host-specific patches ...

My target is new basically.  It's closest to mvsdignus, which
was used as a starting point, but it has evolved.  :-)

>> In the meantime, I have a question.  You said above that I have to
>> point sysroot to the MVS libraries and headers.  What libraries?
>> And why, at the point of building a cross-compiler, do I need any
>> of those things?  The normal way I build a cross-compiler I just
>> do the above configure without prefix or with-sysroot, and it
>> builds an xgcc executable as expected, using the Linux headers,
>> as expected.
>> 
>> I would certainly like an option to force it to use my C90-only
>> Linux headers and my C90-only libraries, but that should be
>> strictly optional, and if I did do that, I would expect to see
>> configure saying things like "no you don't have fork, or getrusage,
>> or sys/types" etc etc.
>> 
>> I think I am still failing to understand some major aspect of the
>> build process.
> 
> Maybe the confusion is about what "sysroot" for a cross-compiler
> means.  The libraries and headers in the sysroot are *not* used
> to build the compiler itself.  You need to specify the sysroot
> location at build time of the compiler only so that this location
> can be compiled into the gcc/cc1 binaries.  Once you later *use*
> the resulting cross-compiler, this cross-compiler will refer to
> the sysroot location for standard headers and libraries.
> 
> That is to say, if you build a cross-compiler with
>    --prefix=/home/gccmvs/cross
>    --sysroot=/home/gccmvs/sysroot
>    --target=i370-mvs
> the result of the build process ("make" and then "make install")
> will be a cross-compiler in /home/gccmvs/cross/bin/i370-mvs-gcc
> (and additional files in /home/gccmvs/cross/lib/gcc/...).

Ok, that's a new concept to me.  Thanks.

> Note that the build process of the compiler itself will refer to
> the host's default headers in /usr/include and libraries in
> /usr/lib.
>
> However, once you *run* this i370-mvs-gcc, and it processes a source
> file using #include <stdio.h>, the compiler will search the directory
> /home/gccmvs/sysroot/include for the stdio.h header file, and it will
> invoke the cross-linker passing /home/gccmvs/sysroot/lib as the 
> location to search for standard libraries like libc.  (Note that the
> names of such standard libraries, if any, are defined by the MVS
> target definitions, in particular the setting of target macros like
> LIB_SPEC in your target header files in config/i370/*.h.)

I don't seem to have that variable defined.  Not surprising since
there's no include or lib directories like that on MVS.

> It is important to get this cross-compiler working correctly, i.e.
> refering to the proper headers and libraries, because in the next
> step, when you configure and build the native compiler, you'll be
> using the cross-compiler, and what headers it uses will determine
> which host features are detected by configure ...

I see.  Anyway, I'll start with raw 3.4.6 and move forward from
there.  The good thing about doing it that way is that I know the end
result is actually achievable.

Gone are the dark days of the 3.2 port where I was doing a lot of
work, and had no idea whether at the end of all that work it would
all be wasted, because the compiler wouldn't run natively due to
some ASCII-specific bug beyond my ability to fix or work around.  :-)

BFN.  Paul.

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> > Huh.  I've never seen this before.  Is this with your patches to
> > generate a "single executable" or without?
> 
> My patches are applied, but shouldn't be activated, because
> I haven't defined SINGLE_EXECUTABLE.
> 
> I could try taking it back to raw 3.4.6 though and see if that has
> the same problem.

Might be interesting ...

> > For the cross-compiler,
> > you shouldn't need any of the MVS host-specific patches ...
> 
> My target is new basically.  It's closest to mvsdignus, which
> was used as a starting point, but it has evolved.  :-)

Host vs. target confusion again? :-)  You have some patches needed
to support MVS as *target* of compilation.  You have some other
patches needed to support MVS as *host* of the compiler itself.

I'm saying that for the cross-compiler, you need the first set
of patches, but you do not need the second set of patches.

For the native compiler, you'll then need both sets ...

> > However, once you *run* this i370-mvs-gcc, and it processes a source
> > file using #include <stdio.h>, the compiler will search the directory
> > /home/gccmvs/sysroot/include for the stdio.h header file, and it will
> > invoke the cross-linker passing /home/gccmvs/sysroot/lib as the 
> > location to search for standard libraries like libc.  (Note that the
> > names of such standard libraries, if any, are defined by the MVS
> > target definitions, in particular the setting of target macros like
> > LIB_SPEC in your target header files in config/i370/*.h.)
> 
> I don't seem to have that variable defined.  Not surprising since
> there's no include or lib directories like that on MVS.

I'm not sure how this works on MVS, but the C standard says that if
your application uses #include <stdio.h>, this must work and find
the appropriate system header ...

When running the compiler natively on MVS, there may not be a notion
of "directories" in the Unix sense, but I guess those headers must
still come from *somewhere*, right?

For the *cross-compiler*, because it is hosted on a Unix system, it
must provide those same headers in a directory somewhere.  This is
the directory you specify via --with-sysroot.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

>> > Huh.  I've never seen this before.  Is this with your patches to
>> > generate a "single executable" or without?
>> 
>> My patches are applied, but shouldn't be activated, because
>> I haven't defined SINGLE_EXECUTABLE.
>> 
>> I could try taking it back to raw 3.4.6 though and see if that has
>> the same problem.
> 
> Might be interesting ...

Things are never that simple.  :-)

My target isn't in raw 3.4.6, so I had to use a different target (dignus),
which worked!

But dignus no longer worked with my changes.

So had to get dignus working again before I could compare.

I tried other shortcuts, but wasn't successful.

After getting dignus working again I was able to start narrowing
it down.

For some reason gdb doesn't seem to be working as expected,
so had to do without it.

In the end, one line, long forgotten, in my target config file:

#define pwait(a,b,c) (0)

was what was responsible.  :-)  Most of my Posix replacement
functions are in a separate unixio.h, which would normally be
ignored in a configure/real unix environment.  Not sure why this
one ended up there.

Anyway, after that interlude, I can finally move on to the original
challenge!

BFN.  Paul.

Re: i370 port - constructing compile script

[Paul Edwards]

> .../configure --target=i370-mvs --prefix=... --with-sysroot=...  \
>               --enable-languages=c
>
> where prefix points to the directory where the cross-compiler
> should be installed, and sysroot points to the directory where
> the MVS libraries and header are installed.

Ok, I used

../configure --target=i370-mvspdp --prefix=/devel/mvscross --with-sysroot=/devel/mvshead 
 --enable-languages=c

plus make and make install

then I went to

mvscross/bin and renamed i370-mvspdp-gcc to i370-mvspdp-xxx

and replaced it with a script that does:

i370-mvspdp-xxx -S $*

> For step 3 (cross-building a native compiler), you'd need
> something along the lines of
>
>  .../configure --build=i686-linux --host=i370-mvs --target=i370-mvs \
>                --prefix=... --with-build-sysroot=... --enable-languages=c

./configure --build-i686-linux --host=i370-mvspdp --target=i370-mvspdp --prefix=/devel/mvshost 
 --with-build-sysroot=/devel/mvshead --enable-languages=c

I wasn't sure if that --with-build-sysroot was right - pointing to
the same headers, but couldn't think of anything else to do with it!

> This configure run will then use the i370-mvs-gcc cross-compiler
> you built in step 2 in order to detect MVS host properties.

Ok, it (3.4.6 I am using) got as far as:

checking size of void *... configure: error: cannot determine a size of void 
*
make: *** [configure-gcc] Error 1

I haven't had a chance to investigate what it's trying to do there, to
see if I can devise a workaround.

I know that it seems to try to compile with "-g" all the time which
gives a warning about it not being supported, but I don't think
warnings produce bad return codes like that.

BFN.  Paul.

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> Ok, I used
> 
> ../configure --target=i370-mvspdp --prefix=/devel/mvscross --with-sysroot=/devel/mvshead 
>  --enable-languages=c
> 
> plus make and make install
> 
> then I went to
> 
> mvscross/bin and renamed i370-mvspdp-gcc to i370-mvspdp-xxx
> 
> and replaced it with a script that does:
> 
> i370-mvspdp-xxx -S $*

Maybe a more generic way to work around the missing assembler and linker
would be to provide dummy scripts i370-mvspdp-as and i370-mvspdp-ld, where
the "assembler" would simply copy the assembler source input as text to the
"object" file output, and the "linker" would collect all input files into
a tar file (or some other archive) as "executable" output ...

This would allow usual build processes (including "make") to proceed as
expected.

> > For step 3 (cross-building a native compiler), you'd need
> > something along the lines of
> >
> >  .../configure --build=i686-linux --host=i370-mvs --target=i370-mvs \
> >                --prefix=... --with-build-sysroot=... --enable-languages=c
> 
> ./configure --build-i686-linux --host=i370-mvspdp --target=i370-mvspdp --prefix=/devel/mvshost 
>  --with-build-sysroot=/devel/mvshead --enable-languages=c
> 
> I wasn't sure if that --with-build-sysroot was right - pointing to
> the same headers, but couldn't think of anything else to do with it!

That should be fine.  (The --with-build-sysroot option may actually not
be required at all when building just a C compiler.)

> Ok, it (3.4.6 I am using) got as far as:
> 
> checking size of void *... configure: error: cannot determine a size of void 
> *
> make: *** [configure-gcc] Error 1
> 
> I haven't had a chance to investigate what it's trying to do there, to
> see if I can devise a workaround.

The compiler error output found in the config.log file should hopefully
point to the problem ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

>> ../configure --target=i370-mvspdp --prefix=/devel/mvscross --with-sysroot=/devel/mvshead
>>  --enable-languages=c
>>
>> plus make and make install
>>
>> then I went to
>>
>> mvscross/bin and renamed i370-mvspdp-gcc to i370-mvspdp-xxx
>>
>> and replaced it with a script that does:
>>
>> i370-mvspdp-xxx -S $*
>
> Maybe a more generic way to work around the missing assembler and linker
> would be to provide dummy scripts i370-mvspdp-as

I created one of them, but as far as I can tell it didn't pick it up.

> and i370-mvspdp-ld, where
> the "assembler" would simply copy the assembler source input as text to 
> the
> "object" file output, and the "linker" would collect all input files into
> a tar file (or some other archive) as "executable" output ...

Sounds good.

> This would allow usual build processes (including "make") to proceed as
> expected.

Yes.

> The compiler error output found in the config.log file should hopefully
> point to the problem ...

Well, below are some of the changes I made today to get it to go
past the various errors.  Probably the most interesting was this
one:

! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1

I don't have a sys/param.h and so I just stuck those in somewhere
that it seemed to be looking for, so that it didn't come up and say
that it couldn't determine the endian order.

It seemed to try very hard to stick in sys/types.h and sys/time.h
and I'm not sure how well I got around that.

It also seemed to execute /bin/as at one point instead of my
dummy cross-assembler.  I'll try to figure out what the logic
is tomorrow.

Note - all this is on 3.4.6.

BFN.  Paul.




Index: configure
===================================================================
RCS file: /cvsroot/gccnew/gcc/configure,v
retrieving revision 1.1.1.1
retrieving revision 1.8
diff -c -r1.1.1.1 -r1.8
*** configure 9 Jul 2009 00:25:05 -0000 1.1.1.1
--- configure 20 Oct 2009 12:39:48 -0000 1.8
***************
*** 2463,2470 ****
  /* end confdefs.h.  */
  #include <stdarg.h>
  #include <stdio.h>
! #include <sys/types.h>
! #include <sys/stat.h>
  /* Most of the following tests are stolen from RCS 5.7's src/conf.sh.  */
  struct buf { int x; };
  FILE * (*rcsopen) (struct buf *, struct stat *, int);
--- 2463,2470 ----
  /* end confdefs.h.  */
  #include <stdarg.h>
  #include <stdio.h>
! /*#include <sys/types.h>
! #include <sys/stat.h>*/
  /* Most of the following tests are stolen from RCS 5.7's src/conf.sh.  */
  struct buf { int x; };
  FILE * (*rcsopen) (struct buf *, struct stat *, int);
***************
*** 3377,3383 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3377,3383 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 3448,3454 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3448,3454 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 3519,3525 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3519,3525 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 3590,3596 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3590,3596 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 3662,3668 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3662,3668 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 3735,3741 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! #include <sys/types.h>


  int
--- 3735,3741 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
! /*#include <sys/types.h>*/


  int
***************
*** 5656,5662 ****
  if test $ac_cv_header_time = yes; then

  cat >>confdefs.h <<\_ACEOF
! #define TIME_WITH_SYS_TIME 1
  _ACEOF

  fi
--- 5656,5662 ----
  if test $ac_cv_header_time = yes; then

  cat >>confdefs.h <<\_ACEOF
! /*#define TIME_WITH_SYS_TIME 1*/
  _ACEOF

  fi
***************
*** 6150,6157 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
! #include <sys/param.h>
  int
  main ()
  {
--- 6150,6160 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
! #include <sys/param.h>*/
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1
  int
  main ()
  {
***************
*** 6192,6199 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
! #include <sys/param.h>
  int
  main ()
  {
--- 6195,6205 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
! #include <sys/param.h>*/
! #define BIG_ENDIAN 1
! #define LITTLE_ENDIAN 2
! #define BYTE_ORDER 1
  int
  main ()
  {
***************
*** 6731,6738 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
! #include <inttypes.h>
  int
  main ()
  {
--- 6737,6744 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
! #include <inttypes.h>*/
  int
  main ()
  {
***************
*** 7051,7057 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>

  _ACEOF
  if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
--- 7057,7063 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>*/

  _ACEOF
  if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
***************
*** 7093,7099 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  /* Thanks to Mike Rendell for this test.  */
! #include <sys/types.h>
  #define NGID 256
  #undef MAX
  #define MAX(x, y) ((x) > (y) ? (x) : (y))
--- 7099,7105 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  /* Thanks to Mike Rendell for this test.  */
! /*#include <sys/types.h>*/
  #define NGID 256
  #undef MAX
  #define MAX(x, y) ((x) > (y) ? (x) : (y))
***************
*** 7303,7311 ****
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! #include <sys/types.h>
  #include <sys/mman.h>
! #include <unistd.h>

  #ifndef MAP_ANONYMOUS
  #define MAP_ANONYMOUS MAP_ANON
--- 7309,7317 ----
  cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
! /*#include <sys/types.h>
  #include <sys/mman.h>
! #include <unistd.h>*/

  #ifndef MAP_ANONYMOUS
  #define MAP_ANONYMOUS MAP_ANON
***************
*** 7644,7650 ****
  else
    cat >conftest.$ac_ext <<_ACEOF
  /* By Ruediger Kuhlmann. */
!       #include <sys/types.h>
        #if HAVE_UNISTD_H
        # include <unistd.h>
        #endif
--- 7650,7656 ----
  else
    cat >conftest.$ac_ext <<_ACEOF
  /* By Ruediger Kuhlmann. */
!       /*#include <sys/types.h>*/
        #if HAVE_UNISTD_H
        # include <unistd.h>
        #endif
***************
*** 7717,7725 ****
  /* Thanks to Paul Eggert for this test.  */
  #include <stdio.h>
  #include <stdlib.h>
! #include <sys/types.h>
  #include <sys/stat.h>
! #include <sys/wait.h>
  #if HAVE_UNISTD_H
  # include <unistd.h>
  #endif
--- 7723,7731 ----
  /* Thanks to Paul Eggert for this test.  */
  #include <stdio.h>
  #include <stdlib.h>
! /*#include <sys/types.h>
  #include <sys/stat.h>
! #include <sys/wait.h>*/
  #if HAVE_UNISTD_H
  # include <unistd.h>
  #endif
***************
*** 8998,9004 ****
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */

! #include <sys/types.h>
  #ifdef HAVE_SYS_STAT_H
  # include <sys/stat.h>
  #endif
--- 9004,9010 ----
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */

! /*#include <sys/types.h>*/
  #ifdef HAVE_SYS_STAT_H
  # include <sys/stat.h>
  #endif

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> > Maybe a more generic way to work around the missing assembler and linker
> > would be to provide dummy scripts i370-mvspdp-as
> 
> I created one of them, but as far as I can tell it didn't pick it up.

Ah, you'll probably have to re-run configure and rebuild the cross compiler.
The configure/build process checks for the presence of the cross-assembler
and decides which one to use.

> > The compiler error output found in the config.log file should hopefully
> > point to the problem ...
> 
> Well, below are some of the changes I made today to get it to go
> past the various errors.  Probably the most interesting was this
> one:
> 
> ! #define BIG_ENDIAN 1
> ! #define LITTLE_ENDIAN 2
> ! #define BYTE_ORDER 1
> 
> I don't have a sys/param.h and so I just stuck those in somewhere
> that it seemed to be looking for, so that it didn't come up and say
> that it couldn't determine the endian order.

Hmm, it seems configure does use a couple of fallbacks to determine
byte order if sys/param.h doesn't exist, but those require a working
cross-assembler ...

> It seemed to try very hard to stick in sys/types.h and sys/time.h
> and I'm not sure how well I got around that.

Generally speaking, the configure process should work on non-POSIX
systems that don't provide those headers.  But it may well be that
something is broken in this case; this will be rarely tested ...

> It also seemed to execute /bin/as at one point instead of my
> dummy cross-assembler.  I'll try to figure out what the logic
> is tomorrow.

See above; you should try to rebuild the cross-compiler first.


> Index: configure
> ===================================================================
> RCS file: /cvsroot/gccnew/gcc/configure,v

For now, just patching configure to see how far you get is of course fine.
Longer term, however, note that configure is a generated file.  You'd have
to make those changes either in configure.ac or possible within the
autoconf machinery that generates the file.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

Well, I have good news to report.  The restructuring was a success.

That means with those 30-odd changes to the configure scripts, I
was able to get an auto-host.h built that allowed me to take the
generated source and compile it with my own scripts as per
normal.

There's still a stack more work to do of course, such as reversing
out the ansidecl.h change, which is pretty horrible:

#ifdef PUREISO
#include "../gcc/unixio.h"
#include "../gcc/config/i370/mvspdp.h"
#endif

I needed to put in the relative path to allow compilation.

However, now I would like to know:

1. I think my unixio.h, which has a stack of POSIX functions
that need to be there (mkdir, pwait, open, fileno etc), needs to
be considered "honorary ansi" (after all, so much code assumes
that they exist) and get included in ansidecl, with unixio.h
living in include, and unixio.c living in libiberty.  Does that
sound reasonable?

2. A 3rd EBCDIC port has recently been achieved - MUSIC/SP.
As part of doing that port I ran into an old problem - IFOX's
399 external limitation.  On MVS and CMS we had people who
knew how to modify IFOX.  On MUSIC, we don't.  I have a code
workaround:

#define flag_test_coverage gflags[0]
#define flag_branch_probabilities gflags[1]
#define flag_reorder_blocks gflags[2]
#define flag_reorder_functions gflags[3]
#define flag_rename_registers gflags[4]
#define flag_force_mem gflags[5]
#define flag_force_addr gflags[6]
#define flag_defer_pop gflags[7]
#define flag_float_store gflags[8]
#define flag_strength_reduce gflags[9]

etc

What would be really good is if flags.h and toplev.c had a 
consecutive block of flags, so that even if my few lines of
intrusive code aren't accepted, it's at least easy for me to
mask out an entire block.  At the moment I have to look
for a few largish chunks of flags to mask out.

I'm not sure how many I need to mask out in total.  I'll be
experimenting with that in the coming days on one computer,
while on the other computer I will be getting the compile
scripts auto-generated from the file list.  I haven't tried
linking with the auto-generated file list yet.  I know that
it is a bit different from my list (by something like 10 files),
but haven't yet determined if it is functional anyway.

I'll come back to making the configure changes more
streamlined after the rest of the stuff is working.

BTW, with MUSIC/SP done, VSE is the only currently-used
EBCDIC programming environment without a GCC port, and
in fact, probably the only computer system (definition:
has assembler, has editor, has programmers who use that
editor, commercially-used) in existence without a free C 
compiler (and thus, to me, preventing C from being a truly
universal language for computers).  And there's only about 
1000 lines of assembler in the way of that happening.  
Unfortunately it's the same 1000 lines we've been waiting for 
several years for.  :-)  But I will be concentrating on making
the MUSIC/SP port look nicer first.  If I can get DYNALLOC
working for output datasets, it should be fine.  Otherwise,
the workaround for that problem is pretty horrible.  :-)

Anyway, thanks guys for your help.  I'll post the code after
I've cleaned it up further.

BFN.  Paul.

Re: i370 port - constructing compile script

[Ralf Wildenhues]

Hello Paul,

* Paul Edwards wrote on Thu, Nov 12, 2009 at 03:02:59PM CET:
> Well, I have good news to report.  The restructuring was a success.
> 
> That means with those 30-odd changes to the configure scripts, I
> was able to get an auto-host.h built that allowed me to take the
> generated source and compile it with my own scripts as per
> normal.

It would be a good idea if you took the extra mile and reported all
these changes to the bug-autoconf mailing list, so it could be fixed
for good there.

Furthermore, it would be really good if we could get Autoconf to build
and run on your system, so you could run its test suite there.  That
would provide much better coverage of all the issues that would need
fixing, and allow us to fix them once in the macros, instead of having
you do this repeatedly in every configure script.

However, Autoconf requires Perl and GNU M4 (and some shell environment
as well as a make program), so I'm not sure whether it is possible to
get to this point.

Thanks,
Ralf

Re: i370 port - constructing compile script

[Paul Edwards]

> * Paul Edwards wrote on Thu, Nov 12, 2009 at 03:02:59PM CET:
>> Well, I have good news to report.  The restructuring was a success.
>>
>> That means with those 30-odd changes to the configure scripts, I
>> was able to get an auto-host.h built that allowed me to take the
>> generated source and compile it with my own scripts as per
>> normal.
>
> It would be a good idea if you took the extra mile and reported all
> these changes to the bug-autoconf mailing list, so it could be fixed
> for good there.

I was under the impression that the root cause was a problem
with configure.ac in gcc rather than autoconf.  However, I took
a look at that file, and I can only see a couple of references
to sys/types.h, none of which look the same as the sort of
thing I needed to change.

  /* end confdefs.h.  */
  #include <stdarg.h>
  #include <stdio.h>
+ #if !defined(__MVS__)
  #include <sys/types.h>
  #include <sys/stat.h>
+ #endif

  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
  #include "confdefs.h"
+ #if !defined(__MVS__)
  #include <sys/types.h>
+ #endif

> Furthermore, it would be really good if we could get Autoconf to build
> and run on your system, so you could run its test suite there.  That
> would provide much better coverage of all the issues that would need
> fixing, and allow us to fix them once in the macros, instead of having
> you do this repeatedly in every configure script.

I am running on a Linux box!  The thing I am doing that is unusual
is two things:

1. Only providing C90 headers when cross-building a host.  That
means that things like sys/types are failing.

2. No linking is done, because I don't have a cross-linker.

As far as I can tell, peculiarity number 2 has not caused the need
for any changes, with the possible exception of ones like this:

+ #if !defined(__MVS__)
  #include <sys/types.h>
  #include <sys/param.h>
+ #endif
+ #if defined(__MVS__)
+ #define BIG_ENDIAN 1
+ #define LITTLE_ENDIAN 2
+ #define BYTE_ORDER 1
+ #endif

I'm not sure what that one was all about, and I'm not sure the
result of it is even used.

Note that peculiarity 2 ideally requires prototypes for all
functions, so there were a couple of other changes made to the
gcc 3.4.6 code, such as this one:

  #ifdef HAVE_SYS_RESOURCE_H
  #include <sys/resource.h>
  #endif
! #if defined (HAVE_DECL_GETRUSAGE) && !HAVE_DECL_GETRUSAGE
  extern int getrusage (int, struct rusage *);
  #endif

--- 86,100 ----
  #include "prefix.h"
  #include "gcc.h"
  #include "flags.h"

  #ifdef HAVE_SYS_RESOURCE_H
  #include <sys/resource.h>
  #endif
! #if defined (HAVE_GETRUSAGE) && !HAVE_DECL_GETRUSAGE
  extern int getrusage (int, struct rusage *);
  #endif

Anyway, all of this should be reproducible building any ASCII
target on any ASCII machine, just by using a C90 set of head
files and a dummy compile script like this:

C:\devel\gccnew\gcc\config\i370>type i370-mvspdp-gcc
echo $* >>/tmp/build.txt
i370-mvspdp-xxx -Werror-implicit-function-declaration -DPUREISO -S -I 
/devel/mvshead/usr/include $*

Note the '-S' which could be '-c' instead and the -W.

> However, Autoconf requires Perl and GNU M4 (and some shell environment
> as well as a make program), so I'm not sure whether it is possible to
> get to this point.

Those are all available on the build machine, even though, out of those,
only m4 is available on the host.  :-)

BFN.  Paul.

Re: i370 port - constructing compile script

[Paul Edwards]

Ok, now I have some results from the auto-compile-script-generation.

I got it to work, but it required some manual corrections.

First of all, I got link errors, because sched-ebb etc were trying
to call various functions, but those functions were not being
compiled in because INSN_SCHEDULING was not defined
(that's my quick analysis, anyway).  So I just grepped those
files out of the "source list".

Next, a stack of libiberty files were not compiled - strcasecmp,
vasprintf, asprintf, getpagesize, strdup.  I don't know why this
would be the case, because e.g. HAVE_STRCASECMP is
not defined.  Anyway, I added them to the source list manually,
and with a script, awk and m4, I was able to produce my
traditional compile script (which is a stepping stone for doing
the same thing on MVS).

Oh, one other change I made - I normally define PREFIX in a
common header file.  However, this caused a conflict between
prefix.c and regex.c which both try to use this keyword.  It
would be good if this define was made unique within the
source base.  I realise there are different ways around this,
but it would still be good to be unique.  For now I just updated
prefix.c to use "" as a default prefix if none is provided.  That's
neater than any immediate alternative I can think of.

But anyway, the short story is that things are looking great,
and it is looking like I have managed to slot into the existing
build process with fairly minimal intrusive code, which bodes
well for a future GCC 4 port attempt.  :-)  The remaining work
I know of doesn't require any more intrusive code.

BFN.  Paul.

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> First of all, I got link errors, because sched-ebb etc were trying
> to call various functions, but those functions were not being
> compiled in because INSN_SCHEDULING was not defined
> (that's my quick analysis, anyway).  So I just grepped those
> files out of the "source list".

This is apparently a bug in the 3.4 version of sched-ebb.c.  This
whole file should be in a #ifdef INSN_SCHEDULING, just like the
other sched-*.c files.  This is fixed in current GCC.

> Next, a stack of libiberty files were not compiled - strcasecmp,
> vasprintf, asprintf, getpagesize, strdup.  I don't know why this
> would be the case, because e.g. HAVE_STRCASECMP is
> not defined.  Anyway, I added them to the source list manually,
> and with a script, awk and m4, I was able to produce my
> traditional compile script (which is a stepping stone for doing
> the same thing on MVS).

The libiberty configure process attempts to detect which functions
need to be built via link tests by default.  As you don't have a
cross-linker, something may be going wrong here.  As an alternative,
you can hard-code which functions to use in libiberty's configure.ac.

> Oh, one other change I made - I normally define PREFIX in a
> common header file.  However, this caused a conflict between
> prefix.c and regex.c which both try to use this keyword.  It
> would be good if this define was made unique within the
> source base.  I realise there are different ways around this,
> but it would still be good to be unique.  For now I just updated
> prefix.c to use "" as a default prefix if none is provided.  That's
> neater than any immediate alternative I can think of.

Why would you define this by hand?  The usual make process will
define PREFIX while building prefix.c, using the appropriate
value determined at configure time ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

>> Next, a stack of libiberty files were not compiled - strcasecmp,
>> vasprintf, asprintf, getpagesize, strdup.  I don't know why this
>> would be the case, because e.g. HAVE_STRCASECMP is
>> not defined.  Anyway, I added them to the source list manually,
>> and with a script, awk and m4, I was able to produce my
>> traditional compile script (which is a stepping stone for doing
>> the same thing on MVS).
> 
> The libiberty configure process attempts to detect which functions
> need to be built via link tests by default.  As you don't have a
> cross-linker, something may be going wrong here.  As an alternative,
> you can hard-code which functions to use in libiberty's configure.ac.

The thing is, I already know it has detected that I don't have
strcasecmp.  That's why it doesn't have HAVE_STRCASECMP
defined in the config.h.  You are right that I don't have a linker,
but the compile with error-on-no-prototype is working fine - I
can see the result in config.h.

>> Oh, one other change I made - I normally define PREFIX in a
>> common header file.  However, this caused a conflict between
>> prefix.c and regex.c which both try to use this keyword.  It
>> would be good if this define was made unique within the
>> source base.  I realise there are different ways around this,
>> but it would still be good to be unique.  For now I just updated
>> prefix.c to use "" as a default prefix if none is provided.  That's
>> neater than any immediate alternative I can think of.
> 
> Why would you define this by hand?  The usual make process will
> define PREFIX while building prefix.c, using the appropriate
> value determined at configure time ...

Because when my assemble and compile jobs start running on
MVS, I would first of all need to put in a special define for that
in the compile step for prefix - the only exception in fact.  Secondly,
I am running close to the 100-character limit of the PARM
statement already, with the things I was forced to add:

//ST2CMP   PROC GCCPREF='GCC',MEMBER='',
// PDPPREF='PDPCLIB',
// COS1='-Os -S -ansi -pedantic-errors -remap -DHAVE_CONFIG_H',
// COS2='-DIN_GCC -DPUREISO -o dd:out -'

Having another define, just to define an empty string, seems very
ugly indeed, even assuming it comes in under 100 characters.

By the way - that previous discussion we had about the potential
for the MVS version to one day be able to do a system().  Even
if it works for MVS eventually, which it probably will, it won't
work for MUSIC/SP in batch.  It's tragic, because I wanted to
use exactly that to issue a "/file" for dynamic file allocation
similar to how the CMS port does.  I only have one other
option - maybe the DYNALLOC call will work under MUSIC/SP,
which would be nicer than doing a "/file" anyway.  I will be trying
that in the days ahead, but regardless, I need gcc to be a
single executable on that environment if I want to run in batch.
And yes, I want to run my compiles in batch!  :-)

BFN.  Paul.

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> The thing is, I already know it has detected that I don't have
> strcasecmp.  That's why it doesn't have HAVE_STRCASECMP
> defined in the config.h.  You are right that I don't have a linker,
> but the compile with error-on-no-prototype is working fine - I
> can see the result in config.h.

Well, the configure process should result in the variable LIBOBJS
in the generated libiberty Makefile to be set to list of objects
containing implementations of replacement system routines.

This gets set during the macro call
  AC_REPLACE_FUNCS($funcs)
in configure.ac, which gets replaced by the following code
in configure (GCC 3.4):

for ac_func in $funcs
do
as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
echo "$as_me:$LINENO: checking for $ac_func" >&5
echo $ECHO_N "checking for $ac_func... $ECHO_C" >&6
[...]
if test `eval echo '${'$as_ac_var'}'` = yes; then
  cat >>confdefs.h <<_ACEOF
#define `echo "HAVE_$ac_func" | $as_tr_cpp` 1
_ACEOF

else
  LIBOBJS="$LIBOBJS $ac_func.$ac_objext"
fi
done

So if you do not have HAVE_STRCASECMP in config.h, you should
have been getting strcasecmp.o in LIBOBJS ...

> > Why would you define this by hand?  The usual make process will
> > define PREFIX while building prefix.c, using the appropriate
> > value determined at configure time ...
> 
> Because when my assemble and compile jobs start running on
> MVS, I would first of all need to put in a special define for that
> in the compile step for prefix - the only exception in fact.  Secondly,
> I am running close to the 100-character limit of the PARM
> statement already, with the things I was forced to add:
> 
> //ST2CMP   PROC GCCPREF='GCC',MEMBER='',
> // PDPPREF='PDPCLIB',
> // COS1='-Os -S -ansi -pedantic-errors -remap -DHAVE_CONFIG_H',
> // COS2='-DIN_GCC -DPUREISO -o dd:out -'
> 
> Having another define, just to define an empty string, seems very
> ugly indeed, even assuming it comes in under 100 characters.

Ah, OK.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

> Well, the configure process should result in the variable LIBOBJS
> in the generated libiberty Makefile to be set to list of objects
> containing implementations of replacement system routines.
> 
> So if you do not have HAVE_STRCASECMP in config.h, you should
> have been getting strcasecmp.o in LIBOBJS ...

And indeed, I sort of am.

LIBOBJS includes a strcasecmp.s$U.s

That suffix is certainly strange-looking though.  I checked in
config.log and I can see that it automatically detected that
my "object code" has a ".s" extension, which is basically
correct given that I forced the "-S" option.

All of the LIBOBJS are like that.

In addition, there's another problem - it has included strncmp
in the list.  I had a look and it appears that it attempts to
actually run the program to see if strncmp works.  That's
not going to work in a cross-compile environment though.
So maybe it assumes the worst.

I've taken a look at the Makefile to try to find out what is
happening.  It seems that there are REQUIRED_OFILES
which include things like safe-ctype and that has to have
a ".o" extension.  Give that those are hardcoded and
forced to ".o", why isn't LIBOBJS done the same way?

Anyway, I decided to change this:

else
  LIBOBJS="$LIBOBJS $ac_func.$ac_objext"
fi

code you showed earlier to be hardcoded to .o.

And then I changed ac_libobjs to stop putting that $U in 
there as well, and I finally got my strcasecmp.

Note that I also seem to be getting strerror.  It's on the list
of "required files", even though it isn't required or wanted.
configure correctly detected that I already had strerror.
I manually excluded that from my list of files and now things
are looking good again - including strcasecmp being
automatically selected in the build process.  :-)

Hopefully it won't be too much longer before I have the stage 1
JCL being automatically generated so that I can verify the
new files to be compiled actually work on MVS.  :-)

BFN.  Paul.

Re: i370 port - constructing compile script

[Ralf Wildenhues]

* Paul Edwards wrote on Sat, Nov 14, 2009 at 09:51:39AM CET:
> >Well, the configure process should result in the variable LIBOBJS
> >in the generated libiberty Makefile to be set to list of objects
> >containing implementations of replacement system routines.
> >
> >So if you do not have HAVE_STRCASECMP in config.h, you should
> >have been getting strcasecmp.o in LIBOBJS ...
> 
> And indeed, I sort of am.
> 
> LIBOBJS includes a strcasecmp.s$U.s
> 
> That suffix is certainly strange-looking though.  I checked in
> config.log and I can see that it automatically detected that
> my "object code" has a ".s" extension, which is basically
> correct given that I forced the "-S" option.

Why do you pass -S in the compiler script?  configure sort of expects
that neither -S nor -c are passed automatically.

> In addition, there's another problem - it has included strncmp
> in the list.  I had a look and it appears that it attempts to
> actually run the program to see if strncmp works.  That's
> not going to work in a cross-compile environment though.
> So maybe it assumes the worst.

Yes.  The macro that does this is libiberty_AC_FUNC_STRNCMP in
libiberty/aclocal.m4.  In a cross-compile situation, the macro assumes
that strncmp does not work.  It uses the cache variable
ac_cv_func_strncmp_works, which you can set if you need to override the
decision, e.g.:
  ac_cv_func_strncmp_works=yes
  export ac_cv_func_strncmp_works
  ../gcc/configure ...

A more permanent solution would be to set this correctly based upon
$host in libiberty/configure.ac and regenerate libiberty/configure with
autoconf.

> And then I changed ac_libobjs to stop putting that $U in there as
> well, and I finally got my strcasecmp.

Why does that $U hurt you?  It should get expanded to nothing later on.
(It is a remainder from some ansi2knr scheme.)

> Note that I also seem to be getting strerror.  It's on the list
> of "required files", even though it isn't required or wanted.
> configure correctly detected that I already had strerror.
> I manually excluded that from my list of files and now things
> are looking good again - including strcasecmp being
> automatically selected in the build process.  :-)

Again, rather than hacking the generated configure script, I think you
should start modifying the input files, configure.ac in this case, for
permanent solutions to your build issues.  Even if you're only changing
a few lines, doing it each time you want to build a different GCC
version is an unnecessary burden.

Thanks,
Ralf

Re: i370 port - constructing compile script

[Paul Edwards]

>> LIBOBJS includes a strcasecmp.s$U.s
>> 
>> That suffix is certainly strange-looking though.  I checked in
>> config.log and I can see that it automatically detected that
>> my "object code" has a ".s" extension, which is basically
>> correct given that I forced the "-S" option.
> 
> Why do you pass -S in the compiler script?  configure sort of expects
> that neither -S nor -c are passed automatically.

The only thing the compiler is capable of doing is generating
assembler code.  Just getting that to work has been a 20
year effort.

So what I have done is get the compiler to fail on any missing
prototype.  I think perhaps we need to have a generic gcc or
autoconfigure option called "config by prototype".  MVS is just
one instance where you might wish to do it this way.  Other
ports in their infancy may not have working cross-assemblers
and linkers either.  It worked out quite well.

> that strncmp does not work.  It uses the cache variable
> ac_cv_func_strncmp_works, which you can set if you need to override the
> decision, e.g.:
>  ac_cv_func_strncmp_works=yes
>  export ac_cv_func_strncmp_works

Ok, thanks, I've added that, and can confirm that it did the
trick.

> A more permanent solution would be to set this correctly based upon
> $host in libiberty/configure.ac and regenerate libiberty/configure with
> autoconf.

Ok, that's what a lot of this exercise is about - finding out what
needs to be changed in the long term in GCC 4 if MVS is to be
supported.

>> And then I changed ac_libobjs to stop putting that $U in there as
>> well, and I finally got my strcasecmp.
> 
> Why does that $U hurt you?  It should get expanded to nothing later on.
> (It is a remainder from some ansi2knr scheme.)

Ok, I put it back in, and indeed, it does work.  I must have been
confused by an unrelated failure.

>> Note that I also seem to be getting strerror.  It's on the list
>> of "required files", even though it isn't required or wanted.
>> configure correctly detected that I already had strerror.
>> I manually excluded that from my list of files and now things
>> are looking good again - including strcasecmp being
>> automatically selected in the build process.  :-)
> 
> Again, rather than hacking the generated configure script, I think you
> should start modifying the input files, configure.ac in this case, for
> permanent solutions to your build issues.  

As above, that is certainly on the cards.  However, I'm trying
to flesh out the issues that exist before seeing if we can get
agreement for changes in GCC 4.  E.g. what do you think of
the generic "configure by prototype rather than link" facility?
Personally I'd like a "configure by standard" option, where
autoconfigure knows what to do based on me just telling it
that the compiler is C90 (or C99 as another option) compliant,
so that I don't even need to provide headers.  But I think the
header file option is also useful, so both should be selectable.

> Even if you're only changing
> a few lines, doing it each time you want to build a different GCC
> version is an unnecessary burden.

Man, I really wish that was even 1% of the issues that needed to be
sorted out going from GCC 3.4.6 to GCC 4.x.  :-)  I'd be happy to do
it for the rest of my life.  :-)  While the amount of intrusive code is
relatively small, it's still quite widespread.  ie more than 80 files.
And that's just the intrusive code.  There's all the separate port
files that need to be taken care of.  :-)  There's a good reason it took
20 years to get to this point.  :-)

BFN.  Paul.

Re: i370 port - constructing compile script

[Paolo Bonzini]

On 11/14/2009 12:27 PM, Paul Edwards wrote:
>
> So what I have done is get the compiler to fail on any missing
> prototype.  I think perhaps we need to have a generic gcc or
> autoconfigure option called "config by prototype".  MVS is just
> one instance where you might wish to do it this way.  Other
> ports in their infancy may not have working cross-assemblers
> and linkers either.  It worked out quite well.

-Wimplicit -Werror?

Paolo

Re: i370 port - constructing compile script

[Paul Edwards]

Ok, I've now reached a new milestone - the mshort.h which
redefines all the long names into ZZZ_123 etc is now 
automatically generated as part of the build process.

The libiberty and gcc aren't split yet, but I'll probably defer
that to gcc 4, and see if I can simply reproduce what I have
with 3.4.6 first.

But there are some things I want to change in the 3.4.6
before starting that.

There are some files that are being automatically generated
as part of the build process, which I would like to stop.

gcov-iov creates a gcov-iov.h which has a version number
which changes when I change MVS versions.  So I am
thinking of updating gcov-iov.c so that when the target is
MVS, it generates a more fixed format.  Or maybe as part
of the build process I can just put in a
#define GCOV_VERSION 0
Not sure if it's actually being used for anything in my
environment.

gengtype-yacc.c & .h gets created with my new version of bison.
I just want to use the one that came with 3.4.6 instead of
having it regenerated.  Do I need to hide my bison to stop
that from happening?

configargs.h I will just overwrite with something simple as part
of the build process.

gencheck.h is being generated as an empty file, which doesn't
work well on some environments.  I want it to at least have a
comment saying "/* empty file */".  I can put that in as part of
the build script too.

Basically I'm looking for consistent source that won't change
with my build environment.

The raw "MVS source" can then be taken to another environment
to be compiled.

Thanks.  Paul.

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards wrote:

> gcov-iov creates a gcov-iov.h which has a version number
> which changes when I change MVS versions.  So I am
> thinking of updating gcov-iov.c so that when the target is
> MVS, it generates a more fixed format.

I don't see how the generated number depends on the MVS
version ...  It is supposed to depend solely on the *GCC*
version string of the compiler currently being built.

> gengtype-yacc.c & .h gets created with my new version of bison.
> I just want to use the one that came with 3.4.6 instead of
> having it regenerated.  Do I need to hide my bison to stop
> that from happening?

Well, it's just a make step -- the files will get rebuilt if
and only if the gengtype-yacc.y file is more recent than the
gengtype-yacc.c and .h files.  In the default 3.4.6 tarball
this is not the case.  Did you somehow modify file timestamps
while unpacking / copying the files?

> gencheck.h is being generated as an empty file, which doesn't
> work well on some environments.  I want it to at least have a
> comment saying "/* empty file */".  I can put that in as part of
> the build script too.

Well, adding a comment should be trivial at the place in the
Makefile.in where gencheck.h is generated (s-gencheck).

In any case, more recent GCC versions no longer refer to this
file at all.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Paul Edwards]

>> gcov-iov creates a gcov-iov.h which has a version number
>> which changes when I change MVS versions.  So I am
>> thinking of updating gcov-iov.c so that when the target is
>> MVS, it generates a more fixed format.
> 
> I don't see how the generated number depends on the MVS
> version ...  It is supposed to depend solely on the *GCC*
> version string of the compiler currently being built.

Mostly yes.  However, it still grabs the full version string,
which includes the text "MVS 0.X" (which I added, to identify
the sub-version of 3.4.6 on MVS (note that for 3.2.3 I am
up to MVS 7.6 there's been so much activity).  And basically
I don't want that GCOV header file to change between
MVS releases.  Anyway, in the build scripts (ie outside the
normal configure/make process, so no-one needs to see it)
I just overwrite the header, and I didn't notice any ill-effect.

>> gengtype-yacc.c & .h gets created with my new version of bison.
>> I just want to use the one that came with 3.4.6 instead of
>> having it regenerated.  Do I need to hide my bison to stop
>> that from happening?
> 
> Well, it's just a make step -- the files will get rebuilt if
> and only if the gengtype-yacc.y file is more recent than the
> gengtype-yacc.c and .h files.  In the default 3.4.6 tarball
> this is not the case.  Did you somehow modify file timestamps
> while unpacking / copying the files?

Yes, I imported everything into CVS and that presumably changed
all the timestamps.  I wasn't aware of that.  Anyway, I got around
that problem by making dummy changes to the .c and .h and
then reversing them out.  So that is fixed now, thanks.

>> gencheck.h is being generated as an empty file, which doesn't
>> work well on some environments.  I want it to at least have a
>> comment saying "/* empty file */".  I can put that in as part of
>> the build script too.
> 
> Well, adding a comment should be trivial at the place in the
> Makefile.in where gencheck.h is generated (s-gencheck).

Ok, I decided it was better to keep it outside the common files.

> In any case, more recent GCC versions no longer refer to this
> file at all.

And I don't even need to revisit that decision for GCC 4 it seems.  :-)

So I've basically finished doing what I wanted for 3.4.6 now.  I'm
not going to spend time doing niceties like putting the generated
files generation onto MVS so that mainframe users can upgrade
the machine definition without needing a non-MVS machine.  I
have that nicety already for 3.2.3 and I may look into it again
for 4.x.

There's still one last thing for 3.4.6, although it's not really 3.4.6,
I'm doing it for 3.2.3, but will have to incorporate that change into
3.4.6.  And that thing is the MUSIC/SP port.  I have managed to
get dynamic allocation to work, which changes the whole look
of the port, so I'm working through that, which I expect will take
a couple of weeks.  So that will be 3 nicely-working EBCDIC
platforms.  4 if you count USS, but I don't use or test that, so
don't know whether it works there currently.

I should be starting the GCC 4 port in a matter of days, while
using my Unix machine.

Thanks everyone for helping get it to this point.

BFN.  Paul.

Re: i370 port - constructing compile script

[Paolo Bonzini]

On 11/13/2009 12:43 PM, Paul Edwards wrote:
> I normally define PREFIX in a
> common header file.  However, this caused a conflict between
> prefix.c and regex.c which both try to use this keyword.

regex.c is forked from anything else, so I don't think a patch changing 
PREFIX to FUNC_PREFIX will have any objection.

Paolo

Re: i370 port - constructing compile script

[Ulrich Weigand]

Paul Edwards:

> 1. I think my unixio.h, which has a stack of POSIX functions
> that need to be there (mkdir, pwait, open, fileno etc), needs to
> be considered "honorary ansi" (after all, so much code assumes
> that they exist) and get included in ansidecl, with unixio.h
> living in include, and unixio.c living in libiberty.  Does that
> sound reasonable?

Well, it's sort of the whole point of libiberty to provide
functions that are not available on certain hosts, so that
the rest of GCC can be simplified by assuming they're always
there.  So in principle I guess this should be fine.

> What would be really good is if flags.h and toplev.c had a 
> consecutive block of flags, so that even if my few lines of
> intrusive code aren't accepted, it's at least easy for me to
> mask out an entire block.  At the moment I have to look
> for a few largish chunks of flags to mask out.

Note that with current GCC versions, all these flag global
variables are defined by C source code that is automatically
generated from various option parameter files.  This should
make it simpler to change this e.g. to use a struct instead
of many global variables ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: i370 port - constructing compile script

[Michael Matz]

Hi,

On Sun, 4 Oct 2009, Paul Edwards wrote:

> With 3.4.6, I have a script called "compile", which looks like this:
> 
> call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> ...
> gcc -s -nostdlib -o gccmvs.exe *.o ../../pdos/pdpclib/pdpwin32.a -lkernel32
> 
> I believe that a simple script like above can be *generated* with a few 
> lines of changes to an appropriate makefile.  That's why I mentioned 
> before that I'm after a makefile target that only lists the object code 
> that would go into a stage 1 executable.

Ignoring the cross stuff, if this is all you need I would suggest calling 
make in the right way to generate this script.  We'll use a fake 
"compiler" for making cc1 which does nothing else than appending its 
command line to your compile script.  Hence, create a script 
collect-stuff.sh with this content:

-------- snip ----------
#!/bin/sh
echo stdcomp ${1+"$@"} >> /tmp/compile
-------- snap ----------

Now we'll call make so that it only tries to make cc1 with this compiler 
to collect the commands:

% cd gcc
% make CC=collect-stuff.sh cc1

/tmp/compile will now fill up with the commands to use.  If you don't need 
the various options, also add "ALL_COMPILERFLAGS= ALL_CPPFLAGS=" to the 
make command (might be other variable names in the old 4.x compilers), or 
amend the collect-stuff.sh script to not echo them.

Remember to clean the build dir before doing this as otherwise some .o 
files aren't remade.


Ciao,
Michael.

Re: i370 port - constructing compile script

[Paul Edwards]

> .../configure --target=i370-mvs --prefix=... --with-sysroot=...  \
>               --enable-languages=c

Thanks Ulrich.  That's very different from the concept I had of
how the build process was meant to work.

> Ignoring the cross stuff, if this is all you need I would suggest calling
> make in the right way to generate this script.  We'll use a fake
> "compiler" for making cc1 which does nothing else than appending its
> command line to your compile script.  Hence, create a script
> collect-stuff.sh with this content:
>
> -------- snip ----------
> #!/bin/sh
> echo stdcomp ${1+"$@"} >> /tmp/compile
> -------- snap ----------
>
> Now we'll call make so that it only tries to make cc1 with this compiler
> to collect the commands:
>
> % cd gcc
> % make CC=collect-stuff.sh cc1

Thanks Michael.  That's exactly the sort of thing I was after.  Just
one thing - I'll need more than cc1.  I need the files that normally
go into gcc as well.  So a combination of those two sets of source,
so that I can get a single standalone executable.  So I'll need to
create a new Makefile target that's a bit bigger than cc1.  But
cc1 will come close.

Also, I decided that I'd better go back to gcc 3.4.6 in order to do
this experimentation, because at least with that I know that at
the end of the day, there's no compiler issue, so if it doesn't
work, the fault must lie withe the build process.

I can't say that about 4.4, because I already know a normally
built cross-compiler on 4.4 with a resuscitated i370 will
build, but has a runtime error which wasn't immediately
obvious (ie gdb didn't point to something wrong).  After 3.4.6
is working, I'll hopefully have an easier time with 4.4.

Anyway, I'll try it out tomorrow etc, and report back the results.

BFN.  Paul.

Re: i370 port - constructing compile script

[Michael Matz]

Hi,

On Tue, 6 Oct 2009, Paul Edwards wrote:

> Thanks Michael.  That's exactly the sort of thing I was after.  Just
> one thing - I'll need more than cc1.  I need the files that normally
> go into gcc as well.  So a combination of those two sets of source,
> so that I can get a single standalone executable.  So I'll need to
> create a new Makefile target that's a bit bigger than cc1.  But
> cc1 will come close.

Add whatever targets you need:

make CC=collect-stuff.sh cc1 xgcc

If you also need some libraries that are normally linked into xgcc or cc1 
(probably at least libiberty and libcpp) do

make CC=collect-stuff.sh -C ../libiberty

too (after having configured everything already).  You'll figure out the 
missing stuff :)


Ciao,
Michael.

Re: i370 port - constructing compile script

[Paul Brook]

> I am happy to construct all of this on a Unix system with the various
> tools (m4 etc) available.
> 
> But from the Unix system, I need to be able to generate the
> above very simple compile script, which is a precursor to creating
> very simple JCL steps (trust me, you don't want to see what
> ST2CMP looks like).  Note that the JCL has the filenames
> truncated to 8 characters, listed twice, uppercased, and '-'
> and '_' converted to '@'.

Have you considered the obvious solution: Don't do that?
i.e. use a cross compiler from a sane system. If you really want to a native 
compiler than I still suggest building it as a canadian cross. My guess is 
that getting gcc hosted in a bizarre environment is much easier than getting 
the gcc build system working. Trying to bootstrap gcc there seems like a lot 
of pain for no real benefit.

Paul

Re: i370 port - constructing compile script

[Paul Edwards]

>> I am happy to construct all of this on a Unix system with the various
>> tools (m4 etc) available.
>>
>> But from the Unix system, I need to be able to generate the
>> above very simple compile script, which is a precursor to creating
>> very simple JCL steps (trust me, you don't want to see what
>> ST2CMP looks like).  Note that the JCL has the filenames
>> truncated to 8 characters, listed twice, uppercased, and '-'
>> and '_' converted to '@'.
>
> Have you considered the obvious solution: Don't do that?
> i.e. use a cross compiler from a sane system. If you really want to a 
> native
> compiler than I still suggest building it as a canadian cross.

That's what this is.

Or at least, replace ST2CMP with ST1CMP and it is the Canadian Cross.

ST1CMP will run the assemblies using HLASM.

Almost identical JCL will run a compile, then an assemble with HLASM.

> My guess is
> that getting gcc hosted in a bizarre environment is much easier than 
> getting

Not so bizarre when so many of the Fortune 500 use it.

> the gcc build system working. Trying to bootstrap gcc there seems like a 
> lot
> of pain for no real benefit.

The effort is mostly in the Canadian Cross.  The changes to get it to
bootstrap from that point are relatively small.  The extra things
required are:

1. header.gcc to remap includes.
2. scripts to rename includes.
3. 20 lines of JCL in the stage 2 procs, to do compiles.

Here's the first of those from 3.4.6, so you can see the scope of
the work:

builtin-attrs.def builtina.h
builtin-types.def builtint.h
builtins.def builtind.h
c-common.def ccommond.h
diagnostic.def diagndef.h
machmode.def machmodd.h
params.def paramsd.h
predict.def predictd.h
rtl.def rtld.h
stab.def stabd.h
timevar.def timevard.h
tree.def treed.h
insn-constants.h i-constants.h
langhooks-def.h langhdef.h
hosthooks-def.h hosthdef.h
gt-dwarf2asm.h gt-dwasm.h
gcov-io.c gcovioc.h

It's now very rare to have a problem on the MVS EBCDIC host that
doesn't also occur on a Unix ASCII cross-compiler.

So for that extra bit of work, mainframers are able to modify the
C compiler on their native platform instead of having to mess
around with a Unix system they know nothing about.

Part of open source is making the source available and
usable on the native environment, I think.  Otherwise, the job
of providing a free, open source C compiler on the mainframe
hasn't really been done, I think.  And I was dreaming of that
way back in 1987 when I had a 3270 terminal plus a
mainframe.  Although admittedly I only wanted to use it, not
build it.  But the easier it is for a mainframer to access the
code, the more likely it is that they will be inspired to add
a PL/S or Cobol front-end to it.

BFN.  Paul.

Re: i370 port - constructing compile script

[Ian Lance Taylor]

"Paul Edwards" <mutazilah@gmail.com> writes:

>> the gcc build system working. Trying to bootstrap gcc there seems
>> like a lot
>> of pain for no real benefit.
>
> The effort is mostly in the Canadian Cross.  The changes to get it to
> bootstrap from that point are relatively small.

I think you are underestimating the work involved.

Many years ago now, when Steve Chamberlain started porting the GNU
tools to bootstrap on Windows, he realized that the best approach was
to write (what is now known as) cygwin.  It may sound crazy now, but
bringing the Unix environment to yours is doable, and it has many
ancillary benefits.

Ian

Re: i370 port - constructing compile script

[Paul Edwards]

>>> the gcc build system working. Trying to bootstrap gcc there seems
>>> like a lot
>>> of pain for no real benefit.
>>
>> The effort is mostly in the Canadian Cross.  The changes to get it to
>> bootstrap from that point are relatively small.
> 
> I think you are underestimating the work involved.

?  Note that I have *already* ported both GCC 3.2.3 and GCC 3.4.6
such that they bootstrap on MVS, in a totally non-Unix environment,
with nothing more than a C90 compiler (with zero (0) extensions).

The trouble is that in the process of doing that (ie mainly for the
Canadian Cross part), I had to:

1. Construct the config.h/auto-host by hand (having the stack
direction go the wrong way was a lot of fun for sure).
2. Got the list of files to compile by hand.
3. Constructed the compile JCL by hand.

I believe all of these things can be integrated into the existing
build process on Unix with minimal fuss if you know where to
put it.

At the time I was doing the original porting, I didn't even have
Unix, so it was easier to do it by hand.

But now I'm interested in neat, minimal integration.  With appropriate
workarounds, GCC is very close to C90 already.

> Many years ago now, when Steve Chamberlain started porting the GNU
> tools to bootstrap on Windows, he realized that the best approach was
> to write (what is now known as) cygwin.  It may sound crazy now, but
> bringing the Unix environment to yours is doable, and it has many
> ancillary benefits.

Adding POSIX to MVS 3.8j is certainly a worthwhile project.

However, I consider bashing GCC into C90-shape to be a worthwhile
project too.  For whenever you're on a non-Posix system, not just
MVS.  E.g. DOS/VS, or CMS, or MUSIC/SP, or TPF, or MVT, or
MFT, or some of the others I have heard mentioned.  :-)

I'm really only interested in DOS/VS, CMS, MUSIC/SP.  Maybe
TPF as well.  But bringing POSIX to them is a separate exercise
to writing the 1000 lines (literally) of assembler that is required to
get them to work.  GCC 3.4.6 is 850,000 lines of (generated)
assembler code.  But the way things are structured, it only requires
1000 lines for each of those different targets (to do I/O).

MVS and CMS are already done.  MUSIC/SP is half done (the
person doing the port died).  DOS/VS is not done, although a
couple of people started an attempt.

Adding POSIX to all those environments may be done at some
point in the future, but no-one has even started, and everyone
wants native support regardless.  Can you imagine if GCC was
running on Unix with some sort of emulated-MVS I/O?  You'd
rip out that nonsense and replace it with native POSIX in an
instant.  CMS actually supports emulated MVS I/O too, and
indeed, that's what the first port was.  But someone has already
spent the effort to replace it with native CMS I/O, which gets
around various restrictions.

I think that we have now reached the point where two quite
different cultures meet.  :-)  People have been freaking out a
bit on the MVS side too.  :-)

BFN.  Paul.

Re: i370 port - constructing compile script

[David Edelsohn]

On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards <mutazilah@gmail.com> wrote:

>>> But from the Unix system, I need to be able to generate the
>>> above very simple compile script, which is a precursor to creating
>>> very simple JCL steps (trust me, you don't want to see what
>>> ST2CMP looks like).  Note that the JCL has the filenames
>>> truncated to 8 characters, listed twice, uppercased, and '-'
>>> and '_' converted to '@'.

Paul,

Why are you not making use of z/OS Unis System Services?  GNU Make and
other GNU tools are available and already built for z/OS.

David

Re: i370 port - constructing compile script

[Toon Moene]

David Edelsohn wrote:

> On Thu, Oct 1, 2009 at 11:59 AM, Paul Edwards <mutazilah@gmail.com> wrote:

>>>> But from the Unix system, I need to be able to generate the
>>>> above very simple compile script, which is a precursor to creating
>>>> very simple JCL steps (trust me, you don't want to see what
>>>> ST2CMP looks like).  Note that the JCL has the filenames
>>>> truncated to 8 characters, listed twice, uppercased, and '-'
>>>> and '_' converted to '@'.

> Paul,
> 
> Why are you not making use of z/OS Unis System Services?  GNU Make and
> other GNU tools are available and already built for z/OS.

Perhaps because he is a hacker in the good ol' sense of the word ?

Mjam, MVS, JCL, the possibility of COBOL, perhaps even PL/1 ...

[ Over a quarter of century ago I worked at the computer center
   of the Dutch Postal Service. One of my colleagues managed the
   IBM system group.  He had an assistant to write the JCL jobs he needed
   for him. ]

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

Re: i370 port - constructing compile script

[Paul Edwards]

>>>>> But from the Unix system, I need to be able to generate the
>>>>> above very simple compile script, which is a precursor to creating
>>>>> very simple JCL steps (trust me, you don't want to see what
>>>>> ST2CMP looks like).  Note that the JCL has the filenames
>>>>> truncated to 8 characters, listed twice, uppercased, and '-'
>>>>> and '_' converted to '@'.
> 
>> Why are you not making use of z/OS Unis System Services?  GNU Make and
>> other GNU tools are available and already built for z/OS.

USS is not available for free, or even for a price on MVS 3.8j,
and it is not native MVS, it is an expensive overhead.

It's a bit like asking "why don't you use a JCL emulator instead 
of make on Unix?".  :-)

You know, even as a batch job with JCL, people then said to me
that reading the C source from a file instead of "standard input"
(ie stdin, ie //SYSIN DD) is really weird, and so I had to make a
pretty small mod to GCC to allow "-" as the filename, so that
the JCL at least looks like a normal MVS compiler.

> Perhaps because he is a hacker in the good ol' sense of the word ?
> 
> Mjam, MVS, JCL, the possibility of COBOL, perhaps even PL/1 ...

Both Cobol and PL/1 front-ends are already supported to some
extent ...

http://www.opencobol.org/

http://pl1gcc.sourceforge.net/

although we're not really at the stage of even attempting to get
that onto native MVS.

Actually, PL/1 basically requires GCC 4.x, which is my main
interest in upgrading 3.4.6 to 4.x.  :-)

Someone else said he would like to see PL/S, and maybe if
PL/1 was available, the super-secret PL/S language would 
start to be made available.

But it all rests on getting the HLASM-generator working on a more
modern GCC.  :-)

And C90 is the lingua franca.

> [ Over a quarter of century ago I worked at the computer center
>   of the Dutch Postal Service. One of my colleagues managed the
>   IBM system group.  He had an assistant to write the JCL jobs he needed
>   for him. ]

Maybe for old times sake you'd like to load up:

http://mvs380.sourceforge.net

It comes with GCC so you can now do what you always wanted
to do back then.  :-)  And of course, all perfectly usable on z/OS
too.  Natively.  :-)

850,000 lines of assembler.  Like wow, man.  I wonder what
GCC 4.4 will clock in as?  3.2.3 was 700,000, so we're probably
up to a million lines of pure 370 assembler.  :-)

BFN.  Paul.