Re: gfc_offset question (32 vs. 64 bits)

[Bud Davis <bdavis9659 at comcast dot net>]

On Sun, 2004-12-19 at 19:31, Paul Brook wrote:
> On Wednesday 15 December 2004 18:36, Jonathan Lennox wrote:
> > Steve Ellcey writes:
> > > Does libgfortran (or any other GCC library) offer a way to pass compiler
> > > option information into a library so it could be used to change the
> > > libraries behaviour?  I guess one could invent a new interface to do
> > > this, I was wondering if there was any existing precedence.
> >
> > I think the most straightforward solution would just be to link in an
> > additional library before libgfortran.
> >
> > My suggestion: define functions
> >
> > gfc_offset _gfortran_read_us_head(gfc_unit*);
> > gfc_offset _gfortran_read_us_tail(gfc_unit*);
> > void _gfortran_write_us_head(gfc_unit*, gfc_offset);
> > void _gfortran_write_us_tail(gfc_unit*, gfc_offset);
> >
> > defined as extern functions in libgfortran, and call them from
> > io/transfer.c as needed.  (Tweak as necessary to get error handling right.)
> >
> > The standard versions can just read and write raw gfc_offset values, as
> > now, assuming that's the desired standard behavior, but a user can
> > optionally link in a library which defines alternate versions of these
> > functions. E.g. "gfortran -o myprog myprog.o -lhp-style-unformatted-files".
> >
> > As long as these libraries are linked before libgfortran, the linker ought
> > to pick up the user's versions of these functions, not libgfortran's. 
> > (This may require a bit of shared library hacking in order to get this to
> > work on all shared library implementations.)
> 
> This seems a good idea.  I'm a bit worried about the shared library issues 
> though.
> 
> I have different suggestion:
> 
> define a library call that specifies the library behaviour. The user can then 
> either call it explicitly from their code, or link in an object with an 
> __attribute__((constructor)) function that does it for them. The big 
> advantage is that it avoids all shared library and linking issues. The 
> downsite is that is doesn't allow a third party custom formats. However new 
> formats can easily be added to libgfortran with minimal maintenance cost, so 
> this probably isn't an issue.
> 
> Paul


just some random thoughts on the topic:


#1.  a compiler option is the cleanest from the user perspective, but
you don't want to make the determination when each module is
compiled...it would be easy to have an executable with inconsistent
object.

thinking in this case that a compiler option would set a flag in the
object that could then direct the i/o library to call the correct 
routine.

not a very good idea.

#2.  environment variables look easiest to implement, but it is not
explicit for the user, probably a source of confusion.

not a great idea.

#3.  user supplied routines are very flexible, but only the hardest
of the hard core users will be able to make it work.

most flexible for the "power users".

#4.  the library call works, but requires user code changes. (paul's
recent idea).

simpler but with some complexity.


What we need is a "compiler option" that really is only used during
the link step.  It would select the correct object to link with to
give the behavior desired.

Here is a snippet of what the top level gfortran or gcc driver does:



 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.0.0/collect2 --eh-frame-hdr
-m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/crtbegin.o
-L/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0
-L/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../.. /tmp/ccxlYNiu.o
-lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/crtend.o /usr/lib/crtn.o


we pull in some individual .o files (yes, I know they are special) and
also a library called gfortranbegin which has only one routine in it.
{so, both are proof that we CAN have individual object files
or libraries with only one member :) }


So, how about this option:

#1.  Make several libraries with the couple of routines to implement
each scheme (libgfortran_crayIO, libgfortan_hpIO, libgfortran_g77IO)
each library implements the same entry points with an identical 
calling sequence. 

#2.  The gfortran or gcc driver get's an additional option to add
the correct library to the link step.  If the option is specified
during a normal compile (.F to .o), it is ignored.


gfortran -fseq_io=HP aaa.f90 -luserlibs -lmoreuserlibs



All the rocket science is moved up to the gcc/gfortran driver code.
gfortran run-time makes a few more libraries, both shared and static,
but the mechanics should be identical to what we do now. 
The user experience is consistent, with a real simple interface that
is documented in the man page. IMHO this is the real issue, if the
user can't figure it out in two sentences of man page, then it
will be a constant source of problems. 

The option names and file names above are notional, we could surely
name them more accurately.


My apologies if I have stolen someone else's idea here; you have to
spell it out in simple terms for me to get it :)  I also made the
mistake of allocating the complexity to something I know nothing
about (gfortran / gcc driver), which means it may not be feasible.


thanks for listening,
bud