[Ecls-list] Help needed, really

[Matthew Mondor]

On Thu, 30 Dec 2010 10:42:43 +0100
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

Sorry that I didn't read the previous discussions, which most probably
happened on another list (and it's unclear to me why OpenAxiom requires
that implementation-dependent low-level information; why it cannot use
an FFI library or standard means such as CL min/max constants such as
MOST-POSITIVE-FIXNUM, MOST-NEGATIVE-FIXNUM to obtain the information it
needs); I'll simply suggest ideas about what I know, hoping they
weren't discussed or dismissed already.  You may cross-post or quote
from this message as wanted.

> I sincerely have no idea how to provide this ABI stuff. The only pieces of
> information that ECL has are C integer sizes (EXT:C-UINT-MAX,
> EXT:C-ULONG-MAX, etc) If someone may infer the appropriate ABI name and
> compiler flags from it, then it is ok, but I do not know how to get that.

Is GNU binutils/objdump capable of distinguishing the various ABIs
properly from a given object file (i.e. especially in the cases you
mentioned where there may be multiple 32-bit and/or 64-bit options on
the same host)?

An awkward runtime ABI detection idea:

If that works, perhaps that we could either copy the method it uses
and include it in a library built with ECL, or include such a tool as
part of the ECL toolchain, for it to at start-time optionally create a
temporary object and infer its ABI, adding the relevant keywords to
*FEATURES*.  Even if that worked though, it has its issues:

- Dependency on GNU toolchain components or equivalent portable code
  such as objdump/readelf/file
- ECL process must compile and write a file somewhere on the file
  system to determine the ABI
- Even if that was done and worked at startup, the information in
  *FEATURES* would be outdated if CL code changes CFLAGS and/or LDFLAGS
  at runtime - Meaning that it might be best to provide a special
  function to infer the ABI instead of providing the information in
  *FEATURES*, which function would most probably be used by software
  also expecting to use the compiler, which would also no longer
  require ECL to need to compile and write to the file system at
  startup.
- If all that complexity is needed, couldn't the third party
  configuration script itself ensure to build the CL implementation
  (ECL in this case) and any other tools it requires together using
  a compatible ABI to avoid the problem?  Or allow/require the user to
  specify the target ABI at project compilation time if they cannot be
  derived from the existing CL implementation alone, and package
  maintainers scripts could pass that parameter if they chose an
  implementation such as ECL for their project...
  (or see below)

> Alternatively I am being asked to provide whether ECL is built with 64-bits
> or 32-bits. I argue that this information is not enough to infer compiler
> flags, for some platforms do provide more than two choices (different 32-bit
> modes, different 64-bit modes, incompatible among them). Furthermore what

I agree, if going in the direction of runtime tests without needing
external tools, by some heuristics we indeed could coarsely distinguish
between little endian and big endian, 32-bit and 64-bit among very
common ABIs, but I'm sure there always will remain cornercases indeed,
especially that ECL allows CFLAGS/LDFLAGS manipulation, which as you
said is a useful feature of ECL and on some toolchains/systems could
change many things.

> ECL does is simply to choose the largest integer that fits a pointer and
> work with that as a fixnum, be it int, long or long long. So there is no
> notion of 64-bit or 32-bit, it is just what the system gives, and I am not
> sure that this may be used to identify the ABI. If it does, it can be
> gathered in a simple way
>     ecl -eval '(print (* 32 (round (/ (integer-length most-positive-fixnum)
> 32))))' -eval '(quit)'
> I understand that this solution is rejected because I am asked to offer a
> 100% relation between this number and the ABI which, as I said, I do not
> feel comfortable to do that.
> 
> It has been repeatedly argued that ECL does know the ABI and that all we are
> doing is hiding it and producing an uncooperative library that does not
> allow itself to be properly linked against other software. This is not the
> image I want to transmit and as you may argue I have no intention to be
> resistive against futher uses of ECL, but I sincerely do not know what I am
> expected to do.

Static ABI idea with optional CC/CFLAGS/LDFLAGS for advanced users:

It might be possible to (optionally, if need be), determine the ABI at
ECL build time (the one used to build ECL itself, probably also the
native toolchain's) and have the necessary information exported as
*FEATURE* keywords, and have ECL runtime ignore by default custom
CC/CFLAGS/LDFLAGS (thus compatible ABI objects would always be
generated) unless ECL would be told to honour them by an advanced user
(with all the risks it entails) using a startup flag, configuration
file option or something akin to package locks, but related to ABI
enforcement...  Possibly that the related *FEATURE* ABI keywords could
also no longer appear when the ABI-LOCK is released.

This also has potential drawbacks:

- ECL itself might ignore the ABI specifics if it doesn't need them,
  but does those *FEATURE* keywords alone satisfy OpenAxiom
  requirements?
- Determining the toolchain's native ABI at ECL build time
- A lock advanced users must now release to enable custom
  compilation/linking flags

After doing a few searches to find out if autoconf reliably can detect
the ABI, it seems that various libraries (such as GMP) require it to be
provided at build-time instead of detecting it.  binutils/objdump could
possibly help, but it would again become a build-time dependency
on a GNU toolchain component.

Another possibility would be to add an (or a few) ABI related option(s)
to ECL configure script and if supplied, enable the ABI-LOCK and export
those extra *FEATURE* keywords, leaving ECL package maintainers the
responsibility to supply it, like for GMP...  ECL behaving as it does
today if they're not specified.

But again: if ECL itself ignores the ABI at runtime but exports the
needed *FEATURE* keywords and provides CL standard min/max constants,
while by default ensuring that custom CC/CFLAGS/LDFLAGS get ignored,
does this satisfy OpenAxiom building requirements?
-- 
Matt