Re: PATCH: Move include/stubs-biarch.h to sysdeps/generic

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 16 Mar 2012, H.J. Lu wrote:

> On Fri, Mar 16, 2012 at 10:37 AM, Roland McGrath <roland@hack.frob.com> wrote:
> >> This patch moves include/stubs-biarch.h to sysdeps/generic so that
> >> each arch can override it with sysdeps/cpu/stubs-biarch.h. ?OK to
> >> install?
> >
> > It seems like stubs-biarch.h and the whole special case for it could be
> > replaced by the genericized logic for multi-variant header generation we
> > talked about for bits/syscall.h and the like. ?That seems like the right
> > thing to do instead.
> 
> As I indicated in my reply to multi-variant header generation. they are
> tied with soversion.i and soversion.mk.  It is much bigger changes than
> I feel comfortable with.

I think stubs.h is probably simpler than lib-names.h - but a proper fix 
may require doing both.

I wonder if shlib-versions files are really doing too much.  Defining the 
details of SONAMEs and symbol versions, for a given ABI, makes sense for 
them.  But perhaps the WORDSIZE and ABI lines give information that should 
be given elsewhere.  WORDSIZE we've found isn't really adequate - after 
all, for x32 you want three variants of this information, not two (and 
it's certainly better to have something generic rather than ad hoc 
architecture-specific code).  As for the ABI lines - shouldn't all the 
other information, such as SONAMEs, be written as a function of the ABI 
name rather than of a regular expression?

So my model might be this: either a makefile, or a configure fragment, 
sets a variable that gives the canonical ABI name for a particular 
configuration.  This name may look similar to a GNU target triplet, but 
need not be identical to one.  These are the same names as presently used 
for baseline files in scripts/data/ - if two builds use the same name, 
they must have the same symbol versions, the same SONAMEs, use the same 
directories for libraries and it won't be possible to put both of them 
inside a single root filesystem because filenames would conflict.  (They 
might still be incompatible in other ways, e.g. big and little endian.)

This ABI name is then what goes on the left of lines in shlib-versions.  
The information that's presently on WORDSIZE lines would be replaced by 
additional information in makefiles, listing the names of the alternate 
ABIs alongside the other information presently listed for bits/syscall.h.

(Maybe there would be separate variables for the CPU part of the ABI name 
and the OS part.)

In any case, if it's concluded that such a cleanup should be done 
separately after the port (with a more ad hoc approach) is in then an 
issue should be filed in Bugzilla to track the desired future cleanup.

-- 
Joseph S. Myers
joseph@codesourcery.com