ABI defaults

[Torbjorn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  Torbjorn Granlund <tg at gmplib.org> writes:
  
  > The part of the configure script which selects assembly path also sets
  > up ABI stuff, and that part needs to be executed also in the non
  > ABI=default case.  We cannot have a if else fi thingy.
  
  I was hoping we can fall down into the case of ABI given explicitly by
  the user. But there's at least one difference; for the ABI=default case,
  the user may already have specified compiler flags to select an ABI.
  
  By the way, which of
  
    ./configure ABI=default CC="gcc -m64"
  
  and
  
    ./configure ABI=default CFLAGS="-m64"
  
  do you think should be the recommended way to set ABI-selection flags
  manually? I imagine it may complicate the code which adds options to
  CFLAGS if we insist on supporting both variants. And we may also need a
  way for the user to say "Use exactly these flags, don't mess with them";
  if explicitly setting CFLAGS should be that way, then the answer to the
  above question ought to be CC="gcc -m64".
  
I think CC="gcc -m32" or CC="gcc -maix64", etc, would be the correct
way.  If we recommend using CFLAGS, people will tend to switch off
optimisation; it would be weird if we overrode CFLAGS, since then there
would be no way to, say, make a debug build without optimisation.

Also, -mblah might work for one compiler but not the compiler that
*works*, making CFLAGS a bad place for compiler specific flags.
Remember that our configure system will sometimes reject the obvious
compiler choice, when that compiler has detected bugs.

  > Perhaps we should split configure.in into several pieces, allowing us to
  > invoke a part from different places?  It is also a very hard-to-read
  > file, and splitting it might be a good idea irrespective of the
  > ABI=default changes.
  
  For a start, it would be an improvement if we could do the ABI and
  compiler selection first, separate from the part of configure which sets
  up the assembly paths. But that sounds like close to a rewrite...
  
The big case statement of CPUs just sets variables, I think.  It should
not hurt that it sets up both paths and compiler flags.  Note that
compiler flags are set up for all known compiler choices for each system
there.

The code that makes use of these variables might need some massaging.

In all this, we must not forget about fat builds...

  >   BTW, do you have a list of which platforms have more choices of ABI than
  >   simply 32-bit or 64-bit? A quick look in configure.in turns up:
  
  Can they be distinguished by looking at the sizes of basic types?
  
No, I don't think all distinctions we want can be made.  I would like
this code to be resilient, depending on sizes would meet these goals.  I
am a bit weary about parsing 'file foo.o' output, which is the only
other ABI detection method of which I am aware.

Perhaps we need to make the code have a failure exit?  Make a best
effort, return ABI if the code is sure, else print a message where users
are encouraged to mail us some output (from file foo.o) and fail?

I suppose another method would be use loop through the ABI compiler
flags we are aware of, and see if we get the same object file for
a plain compiler invocation:

  $CC foo.c -c
  cp foo.o ref.o
  for abi in $abilist
    do
      eval cflags=\"\$${ccbase}${abi}_cflags\"
      $ccbase foo.c -c
      if cmp foo.o ref.o
        then defaultabi=$abi; break
        fi
    done

Untested, probably broken in a few ways.  Object formats that include a
time stamp (such as COFF) will not be detected.

-- 
Torbjörn