public inbox for gas2@sourceware.org
 help / color / mirror / Atom feed
* Has anyone looked at ELF 4.1?
@ 1998-08-08  7:20 H.J. Lu
  1998-08-08 10:02 ` Ulrich Drepper
  1998-08-10 13:51 ` Ian Lance Taylor
  0 siblings, 2 replies; 16+ messages in thread
From: H.J. Lu @ 1998-08-08  7:20 UTC (permalink / raw)
  To: gas2; +Cc: GNU C Library

Hi,

Has anyone looked at ELF 4.1? It is at

http://www.sco.com/products/layered/develop/devspecs/

It is quite interesting. It has something we have talked about a few
month back.


-- 
H.J. Lu (hjl@gnu.org)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-08  7:20 Has anyone looked at ELF 4.1? H.J. Lu
@ 1998-08-08 10:02 ` Ulrich Drepper
  1998-08-08 23:43   ` H.J. Lu
  1998-08-10 13:51 ` Ian Lance Taylor
  1 sibling, 1 reply; 16+ messages in thread
From: Ulrich Drepper @ 1998-08-08 10:02 UTC (permalink / raw)
  To: H.J. Lu; +Cc: gas2, GNU C Library

hjl@lucon.org (H.J. Lu) writes:

> It is quite interesting. It has something we have talked about a few
> month back.

Which extensions do you have in mind?  There is not much new.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-08 10:02 ` Ulrich Drepper
@ 1998-08-08 23:43   ` H.J. Lu
  0 siblings, 0 replies; 16+ messages in thread
From: H.J. Lu @ 1998-08-08 23:43 UTC (permalink / raw)
  To: drepper; +Cc: gas2, libc-hacker

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > It is quite interesting. It has something we have talked about a few
> > month back.
> 
> Which extensions do you have in mind?  There is not much new.
> 
> 

I haven't looked at it in details. It seems to support the OS tag
now.

-- 
H.J. Lu (hjl@gnu.org)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-08  7:20 Has anyone looked at ELF 4.1? H.J. Lu
  1998-08-08 10:02 ` Ulrich Drepper
@ 1998-08-10 13:51 ` Ian Lance Taylor
  1998-08-10 16:54   ` H.J. Lu
  1998-08-11  0:51   ` Roland McGrath
  1 sibling, 2 replies; 16+ messages in thread
From: Ian Lance Taylor @ 1998-08-10 13:51 UTC (permalink / raw)
  To: hjl; +Cc: gas2, libc-hacker

   From: hjl@lucon.org (H.J. Lu)
   Date: Sat, 8 Aug 1998 07:19:38 -0700 (PDT)

   Has anyone looked at ELF 4.1? It is at

   http://www.sco.com/products/layered/develop/devspecs/

   It is quite interesting. It has something we have talked about a few
   month back.

I assume you are referring to EI_OSABI and EI_ABIVERSION.  (Or do you
mean something else?  Why must you be so cryptic?)

As I read it, it's a bit different from the OLF proposal.  SCO is
defining EI_OSABI as indicating whether the file conforms to the
standard ELF format.  A value of 0 (ELFOSABI_SYSV) indicates that the
file does conform.  For EI_ABIVERSION, a conforming application must
use 0.  Our files do conform to the specification (I hope), so it is
correct for us to use 0 for both.

However, we could perhaps ask registry@sco.com to define
ELFOSABI_LINUX, and define that as being the same as the standard, but
using the Linux API.  Similarly for other free operating systems.

Ian

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-10 13:51 ` Ian Lance Taylor
@ 1998-08-10 16:54   ` H.J. Lu
  1998-08-11  0:51     ` Roland McGrath
  1998-08-11  9:22     ` Ian Lance Taylor
  1998-08-11  0:51   ` Roland McGrath
  1 sibling, 2 replies; 16+ messages in thread
From: H.J. Lu @ 1998-08-10 16:54 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gas2, libc-hacker

> As I read it, it's a bit different from the OLF proposal.  SCO is
> defining EI_OSABI as indicating whether the file conforms to the
> standard ELF format.  A value of 0 (ELFOSABI_SYSV) indicates that the
> file does conform.  For EI_ABIVERSION, a conforming application must
> use 0.  Our files do conform to the specification (I hope), so it is
> correct for us to use 0 for both.
> 
> However, we could perhaps ask registry@sco.com to define
> ELFOSABI_LINUX, and define that as being the same as the standard, but
> using the Linux API.  Similarly for other free operating systems.
> 

The purpose of EI_OSABI and EI_ABIVERSION is to tag the OS and ABI.
I think we should register ELFOSABI_LINUX and define it as 1. It may
make many things easier for us. Right now, after I upgrade from
glibc 2.0 to 2.1, groff (man) no longer works since the C++ ABI in
glibc is changed.


-- 
H.J. Lu (hjl@gnu.org)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-10 16:54   ` H.J. Lu
@ 1998-08-11  0:51     ` Roland McGrath
  1998-08-11  9:22     ` Ian Lance Taylor
  1 sibling, 0 replies; 16+ messages in thread
From: Roland McGrath @ 1998-08-11  0:51 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Ian Lance Taylor, gas2, libc-hacker

> The purpose of EI_OSABI and EI_ABIVERSION is to tag the OS and ABI.

It appears so, but the spec should be a whole lot clearer than it is.

> I think we should register ELFOSABI_LINUX and define it as 1. It may
> make many things easier for us.  Right now, after I upgrade from
> glibc 2.0 to 2.1, groff (man) no longer works since the C++ ABI in
> glibc is changed.

That may be a good idea, but the issue you cite is not an argument for it.
We already have the mechanisms of DT_SONAME and the GNU symbol versioning
extensions, so we can fix this problem correctly before deploying glibc
2.1.  If an existing library that was not in error under glibc 2.0 breaks
because of installing glibc 2.1, then it is a bug in glibc 2.1 and we must
be damn sure that we stamp all those out before making the release.  If the
standard C++ libraries used libc internals in glibc 2.0, or only they are
affected by the obscure problem, then it is ok if we require people to
install new C++ libraries in tandem with glibc 2.1.  We just need to be
very clear about the installation procedure, and must make very sure that
all old C++ libraries and programs continue to work with new libraries.  We
can change the sonames if need be, that is better than breaking old
binaries.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-10 13:51 ` Ian Lance Taylor
  1998-08-10 16:54   ` H.J. Lu
@ 1998-08-11  0:51   ` Roland McGrath
  1998-08-11 20:43     ` Geoff Keating
  1 sibling, 1 reply; 16+ messages in thread
From: Roland McGrath @ 1998-08-11  0:51 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gas2, libc-hacker

> As I read it, it's a bit different from the OLF proposal.  SCO is
> defining EI_OSABI as indicating whether the file conforms to the
> standard ELF format.  A value of 0 (ELFOSABI_SYSV) indicates that the
> file does conform.  For EI_ABIVERSION, a conforming application must
> use 0.  Our files do conform to the specification (I hope), so it is
> correct for us to use 0 for both.

I don't know how to read it.  The "standard" is hopelessly vague (if a
unilaterally published document can be called a standard).  They don't
clearly define an ELF standard independent of the SVR4 Unix ABI standard,
so when they say "this specification" I don't know whether that means "the
ELF specification" or "the SVR4 ABI specification".

One sentence is suggestive but mysterious:

	Some fields in other ELF structures have flags and values that have
	platform specific meanings; the interpretation of those fields is
	determined by the value of this byte.

It is certainly not the case that we (intentionally) use on GNU platforms
different "platform specific meanings" for any ELF structure flags or
values that are in the ELF spec.  Aside from SVR4, the one meaningful value
they list is HPUX.  Do you know of any incompatibilites between HPUX's use
of ELF and other ELF implementations?  That might suggest they are talking
about file format compatibility rather than ABI compatibility.  If that is
so, this is an utterly stupid addition.  If HPUX ELF is not compatible with
the existing ELF spec, then HP should use a different EI_VERSION value.

They have conveniently added fields to the header without changing the
EI_VERSION number (which the original spec suggests is intended for such
changes), taking bytes from the EI_PAD area that the old spec reserves to
be zero and making zero mean SVR4.  If they are talking about the ABI,
then that retroactively declares all old ELF binaries to be "officially
marked" as wanting the SVR4 ABI; that is bogus.

> However, we could perhaps ask registry@sco.com to define
> ELFOSABI_LINUX, and define that as being the same as the standard, but
> using the Linux API.  Similarly for other free operating systems.

The community of OS projects using ELF has already adopted an ABI
identification mechanism, using PT_NOTE.  Someone from SCO once said they
would use that scheme too.  But now this totally other thing comes out in
this new spec that, as far as I know, noone in the free OS community was
ever asked about.  Since it says it's a draft, perhaps we can get them to
clean up and clarify the draft and take notice of the rest of the world
that is using ELF.  

A so-called standard is not meaningful or important to adhere to just
because an organization publishes it, and a specification is certainly not
a standard just because one vendor unilaterally declares it so.  We chose
to use ELF as we do now on its merits, and in adding the ABI notes we used
a mechanism that fit in their spec and seemed in the spirit of the spec, to
be nice and try to cooperate helpfully to interoperate.  Now they want to
promulgate a new spec with changes that are not in the spirit of the old
spec and don't use its prescribed procedures for change.

I wish they would clarify their specs to clearly specify the ELF file
format and special section formats unambiguously and independent of the
operating system ABI specification.  That would allow a compilation
toolchain, linker, and dynamic linker, to be clearly correct in their
processing of ELF files independent of how they are implemented and what
ELF files they might be processing.  I don't know if anyone else attempts
to provide such a thing, but GCC, GNU binutils, and the GNU dynamic linker
that's provided in the GNU libc package (but usable independent of what
libraries it loads, as well as being easily portable), together form a
fully complete, correct (we hope) to spec, and highly-portable (not to
mention high-quality, well-supported, and permanently free) set of ELF
tools for a wide variety of processors.  I think we are all proud of this
communal work and the high standard of cross-platform uniformity and
correctness we endeavor to achieve, and it would be nice to have an
unambiguous standard to which we can be definitively correct and measured
against our proprietary peers.

I'm now going to proceed on the assumption that EI_OSABI is intended to
indicate the operating system ABI expected by the program.  I make this
assumption both because of its name, and because adding two fields whose
sole meaning is "yes, really, the same file format spec" is just plain
idiotic and I'm giving SCO a little (perhaps too much) credit for not being
chalk full of complete idiots.  If we can figure out how on earth there can
be a meaningful indicator specified in a standard format that some parts of
the format are nonstandard, maybe it will be become more clear.  Is there
anyone with a brain at SCO or HP that we can ask what the story on this
magic HPUX compatibility value and the horrifying "platform specific
meanings" vagueness?

I agree that the simple two-byte addition in the file header padding area
is nicely compact and easy to check, and if specified properly can be
appropriately and fairly done without changing the header version numbers.
What "specified properly" means is full unambiguous backward compatibility
with the reality of the old specification.  That is, a value of zero in
those positions as required by the old spec should mean "old spec, ABI not
specified" and the suggested practice in encountering such would be to look
for a PT_NOTE like every free OS has been using unambiguously for many
months now.  It is completely bogus to retroactively declare existing ELF
binaries to mean something the format didn't mean in the original spec.
If old SVR4 systems complied with the spec, they ignore those bytes anyhow,
so if they thought all ELF binaries were SVR4 ABI binaries, they won't care
that new SVR4 ABI binaries have a nonzero value in that byte.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-10 16:54   ` H.J. Lu
  1998-08-11  0:51     ` Roland McGrath
@ 1998-08-11  9:22     ` Ian Lance Taylor
  1998-08-16 18:10       ` H.J. Lu
  1 sibling, 1 reply; 16+ messages in thread
From: Ian Lance Taylor @ 1998-08-11  9:22 UTC (permalink / raw)
  To: hjl; +Cc: gas2, libc-hacker

   From: hjl@lucon.org (H.J. Lu)
   Date: Mon, 10 Aug 1998 16:54:32 -0700 (PDT)

   The purpose of EI_OSABI and EI_ABIVERSION is to tag the OS and ABI.
   I think we should register ELFOSABI_LINUX and define it as 1. It may
   make many things easier for us. Right now, after I upgrade from
   glibc 2.0 to 2.1, groff (man) no longer works since the C++ ABI in
   glibc is changed.

This should work anyhow, using the mechanisms we already have.  I
believe it would be a mistake to attempt to characterize library
versions using EI_ABIVERSION.

How precisely would you use ELFOSABI_LINUX to fix this problem?

Ian

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-11  0:51   ` Roland McGrath
@ 1998-08-11 20:43     ` Geoff Keating
  0 siblings, 0 replies; 16+ messages in thread
From: Geoff Keating @ 1998-08-11 20:43 UTC (permalink / raw)
  To: roland; +Cc: ian, gas2, libc-hacker

> Date: Tue, 11 Aug 1998 03:43:58 -0400
> From: Roland McGrath <roland@frob.com>

> I'm now going to proceed on the assumption that EI_OSABI is intended to
> indicate the operating system ABI expected by the program.  I make this
> assumption both because of its name, and because adding two fields whose
> sole meaning is "yes, really, the same file format spec" is just plain
> idiotic and I'm giving SCO a little (perhaps too much) credit for not being
> chalk full of complete idiots.

Have you noticed that the file format now defines OS-specific ranges
for many of the constants?

For instance,

SHT_LOOS      0x60000000
SHT_HIOS      0x6fffffff

Now, if you're going to have such things, it's good to have a tag in
the file format that says what a value of, say, 0x6fffffff means.
In the GNU toolchain, it means 'SHT_GNU_versym'; in Sun's or SGI's
implementation, it might mean something else.  So I imagine that this
is one of the things that EI_OSABI selects.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-11  9:22     ` Ian Lance Taylor
@ 1998-08-16 18:10       ` H.J. Lu
  1998-08-16 18:32         ` Ian Lance Taylor
  1998-08-17 13:14         ` Ulrich Drepper
  0 siblings, 2 replies; 16+ messages in thread
From: H.J. Lu @ 1998-08-16 18:10 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gas2, libc-hacker

> 
>    From: hjl@lucon.org (H.J. Lu)
>    Date: Mon, 10 Aug 1998 16:54:32 -0700 (PDT)
> 
>    The purpose of EI_OSABI and EI_ABIVERSION is to tag the OS and ABI.
>    I think we should register ELFOSABI_LINUX and define it as 1. It may
>    make many things easier for us. Right now, after I upgrade from
>    glibc 2.0 to 2.1, groff (man) no longer works since the C++ ABI in
>    glibc is changed.
> 
> This should work anyhow, using the mechanisms we already have.  I
> believe it would be a mistake to attempt to characterize library
> versions using EI_ABIVERSION.
> 
> How precisely would you use ELFOSABI_LINUX to fix this problem?
> 

The problem with groff is the symbols in libstdc++ are not versioned.
The result is the new stdin/stdout/stderr defined in libstdc++ have
the linkage for the old stdin/stdout/stderr. I don't know how hard
to add symbol versioning to libstdc++. With more and more commercial
softwares available for Linux while glibc 2.1 is still in beta, the
100% backward binary compatibility is a major concern. I'd like to
address with the new ELF specs.

May I suggest:

1. Add switchs to ld to set EI_OSABI and EI_ABIVERSION.
2. For Linux, set EI_ABIVERSION with C ABI and C++ ABI.

	EI_ABIVERSION = (0xf & C_ABI) | (0xf0 & C++_ABI)

3. ld sets EI_OSABI depending on target if it is not set at the command
line.
4. ld sets EI_ABIVERSION depending on EI_ABIVERSION in the shared
library used to build an ELF binary if it is not set at the command
line.
5. The dynamic linker will check both EI_OSABI and EI_ABIVERSION when
choosing which shared library to load. With that, we can have both 2
libc.so.6 with different EI_ABIVERSIONs in different directories.

Thanks.

-- 
H.J. Lu (hjl@gnu.org)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-16 18:10       ` H.J. Lu
@ 1998-08-16 18:32         ` Ian Lance Taylor
  1998-08-16 19:30           ` H.J. Lu
  1998-08-17 13:14         ` Ulrich Drepper
  1 sibling, 1 reply; 16+ messages in thread
From: Ian Lance Taylor @ 1998-08-16 18:32 UTC (permalink / raw)
  To: hjl; +Cc: gas2, libc-hacker

   From: hjl@lucon.org (H.J. Lu)
   Date: Sun, 16 Aug 1998 17:42:55 -0700 (PDT)

   >    The purpose of EI_OSABI and EI_ABIVERSION is to tag the OS and ABI.
   >    I think we should register ELFOSABI_LINUX and define it as 1. It may
   >    make many things easier for us. Right now, after I upgrade from
   >    glibc 2.0 to 2.1, groff (man) no longer works since the C++ ABI in
   >    glibc is changed.
   > 
   > This should work anyhow, using the mechanisms we already have.  I
   > believe it would be a mistake to attempt to characterize library
   > versions using EI_ABIVERSION.
   > 
   > How precisely would you use ELFOSABI_LINUX to fix this problem?

   The problem with groff is the symbols in libstdc++ are not versioned.
   The result is the new stdin/stdout/stderr defined in libstdc++ have
   the linkage for the old stdin/stdout/stderr. I don't know how hard
   to add symbol versioning to libstdc++. With more and more commercial
   softwares available for Linux while glibc 2.1 is still in beta, the
   100% backward binary compatibility is a major concern. I'd like to
   address with the new ELF specs.

You don't have to use symbol versioning.  You can just change the name
of the library in the usual ELF way.  That is easy, and it prevents
any versioning problems due to library code.

If groff once worked, and then broke, then it sounds as though
somebody must have made an incompatible change to the libstdc++
library interface.  Anybody who makes an incompatible change must
change the library version number.  Using the new ELF specs won't save
us from that sort of failure; it is equivalent to failing to increase
the version number in the ELF specs.

What do the new ELF specs give us that we don't get from symbol
versioning and changing library names?

   May I suggest:

   1. Add switchs to ld to set EI_OSABI and EI_ABIVERSION.
   2. For Linux, set EI_ABIVERSION with C ABI and C++ ABI.

	   EI_ABIVERSION = (0xf & C_ABI) | (0xf0 & C++_ABI)

What precisely do you mean here by C_ABI and C++_ABI?  You presumably
do not mean the version of the library, because there is no need to
record that.

Four bits only gives you sixteen versions, which is not a lot.

   3. ld sets EI_OSABI depending on target if it is not set at the command
   line.

How does ld determine EI_OSABI?

   4. ld sets EI_ABIVERSION depending on EI_ABIVERSION in the shared
   library used to build an ELF binary if it is not set at the command
   line.

This seems pointless.  The library version number is already recorded
in the DT_SONAME entry.  If it isn't, then where is it, and how does
ld determine EI_ABIVERSION?

   5. The dynamic linker will check both EI_OSABI and EI_ABIVERSION when
   choosing which shared library to load. With that, we can have both 2
   libc.so.6 with different EI_ABIVERSIONs in different directories.

Why would we want such a thing?

How precisely will this approach help with groff?

I think we have a problem with using multiple libraries which are
linked against different versions of libc.  However, I don't see how
EI_OSABI and EI_ABIVERSION can help with that.

We already have two library versioning schemes: DT_SONAME, and symbol
versioning.  Why do we need a third?  What deficiency in the existing
schemes does it address?

Ian

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-16 18:32         ` Ian Lance Taylor
@ 1998-08-16 19:30           ` H.J. Lu
  1998-08-16 20:01             ` Ian Lance Taylor
  0 siblings, 1 reply; 16+ messages in thread
From: H.J. Lu @ 1998-08-16 19:30 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gas2, libc-hacker

> 
>    From: hjl@lucon.org (H.J. Lu)
>    Date: Sun, 16 Aug 1998 17:42:55 -0700 (PDT)
> 
>    >    The purpose of EI_OSABI and EI_ABIVERSION is to tag the OS and ABI.
>    >    I think we should register ELFOSABI_LINUX and define it as 1. It may
>    >    make many things easier for us. Right now, after I upgrade from
>    >    glibc 2.0 to 2.1, groff (man) no longer works since the C++ ABI in
>    >    glibc is changed.
>    > 
>    > This should work anyhow, using the mechanisms we already have.  I
>    > believe it would be a mistake to attempt to characterize library
>    > versions using EI_ABIVERSION.
>    > 
>    > How precisely would you use ELFOSABI_LINUX to fix this problem?
> 
>    The problem with groff is the symbols in libstdc++ are not versioned.
>    The result is the new stdin/stdout/stderr defined in libstdc++ have
>    the linkage for the old stdin/stdout/stderr. I don't know how hard
>    to add symbol versioning to libstdc++. With more and more commercial
>    softwares available for Linux while glibc 2.1 is still in beta, the
>    100% backward binary compatibility is a major concern. I'd like to
>    address with the new ELF specs.
> 
> You don't have to use symbol versioning.  You can just change the name
> of the library in the usual ELF way.  That is easy, and it prevents
> any versioning problems due to library code.

# ldd /usr/bin/groff
        libstdc++.so.2.8 => /usr/lib/libstdc++.so.2.8 (0x40007000)
        libm.so.6 => /lib/libm.so.6 (0x4004c000)
        libc.so.6 => /lib/libc.so.6 (0x40065000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

The problem is /usr/lib/libstdc++.so.2.8 was compiled again
glibc 2.0.x. When running on a glibc 2.1 machine, /lib/libc.so.6
is glibc 2.1, which supports the same C ABI in glibc 2.0 using
the symbol versioning. But glibc 2.1 has a different C++ ABI.
Please keep in mind that libio in glibc has 2 ABIs, one for C
and the other for C++.

> 
> If groff once worked, and then broke, then it sounds as though
> somebody must have made an incompatible change to the libstdc++
> library interface.  Anybody who makes an incompatible change must
> change the library version number.  Using the new ELF specs won't save
> us from that sort of failure; it is equivalent to failing to increase
> the version number in the ELF specs.

The problem is the incompatible C++ ABIs in libio between glibc 2.0
and glibc 2.1.

> 
> What do the new ELF specs give us that we don't get from symbol
> versioning and changing library names?

We didn't change the library name of libc since the C ABI is ok.
The problem is the C++ ABI in libc. It is very unique to Linux
since we use the same code in libio for both libc and libstdc++.

> 
>    May I suggest:
> 
>    1. Add switchs to ld to set EI_OSABI and EI_ABIVERSION.
>    2. For Linux, set EI_ABIVERSION with C ABI and C++ ABI.
> 
> 	   EI_ABIVERSION = (0xf & C_ABI) | (0xf0 & C++_ABI)
> 
> What precisely do you mean here by C_ABI and C++_ABI?  You presumably
> do not mean the version of the library, because there is no need to
> record that.

No. I mean the ABI version, like

#ifdef glibc 2.0
#define CXX_ABI	0
#define C_ABI	0
#elif defined glibc 2.1
#define CXX_ABI	1
#define C_ABI	0
#endif

> 
> Four bits only gives you sixteen versions, which is not a lot.

I think 16 is more than enough. We may want 3 bits for C++
and 5 bits for C.

> 
>    3. ld sets EI_OSABI depending on target if it is not set at the command
>    line.
> 
> How does ld determine EI_OSABI?

Linker script? We already pass "-dynamic-linker /lib/ld-linux.so.2" to ld for
Linux. We can pass another one if necessary.

> 
>    4. ld sets EI_ABIVERSION depending on EI_ABIVERSION in the shared
>    library used to build an ELF binary if it is not set at the command
>    line.
> 
> This seems pointless.  The library version number is already recorded
> in the DT_SONAME entry.  If it isn't, then where is it, and how does

I am talking about C/C++ ABI version. soname is mainly for C programs
which don't care about the C++ ABI.

> ld determine EI_ABIVERSION?

When we build a dynamic ELF object on Linux, we should always pass
-lc to it. ld can get EI_ABIVERSION from libc.so.

> 
>    5. The dynamic linker will check both EI_OSABI and EI_ABIVERSION when
>    choosing which shared library to load. With that, we can have both 2
>    libc.so.6 with different EI_ABIVERSIONs in different directories.
> 
> Why would we want such a thing?
> 
> How precisely will this approach help with groff?
> 
> I think we have a problem with using multiple libraries which are
> linked against different versions of libc.  However, I don't see how
> EI_OSABI and EI_ABIVERSION can help with that.
> 
> We already have two library versioning schemes: DT_SONAME, and symbol
> versioning.  Why do we need a third?  What deficiency in the existing
> schemes does it address?
> 

We may want to load a different libc.so.6 depending on the C++/C ABI
version. For groff, on glibc 2.1, we want

# ldd /usr/bin/groff
        libstdc++.so.2.8 => /usr/lib/libstdc++.so.2.8 (0x40007000)
        libm.so.6 => /usr/glibc-2.0/lib/libm.so.6 (0x4004c000)
        libc.so.6 => /usr/glibc-2.0/libc.so.6 (0x40065000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)


-- 
H.J. Lu (hjl@gnu.org)

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-16 19:30           ` H.J. Lu
@ 1998-08-16 20:01             ` Ian Lance Taylor
  0 siblings, 0 replies; 16+ messages in thread
From: Ian Lance Taylor @ 1998-08-16 20:01 UTC (permalink / raw)
  To: hjl; +Cc: gas2, libc-hacker

   From: hjl@lucon.org (H.J. Lu)
   Date: Sun, 16 Aug 1998 18:58:10 -0700 (PDT)

   # ldd /usr/bin/groff
	   libstdc++.so.2.8 => /usr/lib/libstdc++.so.2.8 (0x40007000)
	   libm.so.6 => /lib/libm.so.6 (0x4004c000)
	   libc.so.6 => /lib/libc.so.6 (0x40065000)
	   /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

   The problem is /usr/lib/libstdc++.so.2.8 was compiled again
   glibc 2.0.x. When running on a glibc 2.1 machine, /lib/libc.so.6
   is glibc 2.1, which supports the same C ABI in glibc 2.0 using
   the symbol versioning. But glibc 2.1 has a different C++ ABI.
   Please keep in mind that libio in glibc has 2 ABIs, one for C
   and the other for C++.

If the ABI changed between glibc 2.0.x and glibc 2.1, then either the
name of the library has to change or we need to use symbol versioning.

To put it another way, why are those capabilities not adequate to fix
this problem?

I want to make sure that you are fixing a real problem here, not a
problem that has temporarily arisen because glibc happened to not use
symbol versioning for the C++ interface (if that is indeed what
happened).  You are proposing a new capability in the toolchain.  We
should only add it if we need it.

   > If groff once worked, and then broke, then it sounds as though
   > somebody must have made an incompatible change to the libstdc++
   > library interface.  Anybody who makes an incompatible change must
   > change the library version number.  Using the new ELF specs won't save
   > us from that sort of failure; it is equivalent to failing to increase
   > the version number in the ELF specs.

   The problem is the incompatible C++ ABIs in libio between glibc 2.0
   and glibc 2.1.

I don't see how this contradicts the paragraph you quoted.  I said
that anybody who makes an incompatible change must change the library
version number.  You have to explain why neither the library version
number nor the symbol versions changed.

   > What do the new ELF specs give us that we don't get from symbol
   > versioning and changing library names?

   We didn't change the library name of libc since the C ABI is ok.
   The problem is the C++ ABI in libc. It is very unique to Linux
   since we use the same code in libio for both libc and libstdc++.

A change in the C++ ABI is a change in the library ABI.  We use symbol
versioning to give us the ability to change a part of an ABI.  Why
does that not work in this case?

   >    1. Add switchs to ld to set EI_OSABI and EI_ABIVERSION.
   >    2. For Linux, set EI_ABIVERSION with C ABI and C++ ABI.
   > 
   > 	   EI_ABIVERSION = (0xf & C_ABI) | (0xf0 & C++_ABI)
   > 
   > What precisely do you mean here by C_ABI and C++_ABI?  You presumably
   > do not mean the version of the library, because there is no need to
   > record that.

   No. I mean the ABI version, like

   #ifdef glibc 2.0
   #define CXX_ABI	0
   #define C_ABI	0
   #elif defined glibc 2.1
   #define CXX_ABI	1
   #define C_ABI	0
   #endif

That is not an explanation.  What do you mean by C_ABI?  If we change
the name of the library, does the C_ABI change?  Why or why not?

   > Four bits only gives you sixteen versions, which is not a lot.

   I think 16 is more than enough. We may want 3 bits for C++
   and 5 bits for C.

How is 16 more than enough?  What kind of time frame are you thinking
of?  You're saying that the C++ ABI needs to change from glibc 2.0 to
2.1.  Won't it change just about every time a new library is released?
If not, why not?

   >    3. ld sets EI_OSABI depending on target if it is not set at the command
   >    line.
   > 
   > How does ld determine EI_OSABI?

   Linker script? We already pass "-dynamic-linker /lib/ld-linux.so.2" to ld for
   Linux. We can pass another one if necessary.

Making the compiler aware of the dynamic linker version number in this
way is a bogus hack, since it makes the compiler unnecessarily
dependent on the system version number.  You really ought to be able
to use the same compiler on most Linux versions.  After all, the code
generation doesn't change, and all the system dependencies are
reflected in the header files.  Introducing another system dependency
into the compiler is a step backward, not forward.

   >    4. ld sets EI_ABIVERSION depending on EI_ABIVERSION in the shared
   >    library used to build an ELF binary if it is not set at the command
   >    line.
   > 
   > This seems pointless.  The library version number is already recorded
   > in the DT_SONAME entry.  If it isn't, then where is it, and how does

   I am talking about C/C++ ABI version. soname is mainly for C programs
   which don't care about the C++ ABI.

No.  DT_SONAME is for anybody who uses a library, and it applies to
all interfaces of the library.  It is a bug to think that DT_SONAME
only applies to part of a library's interface.

   > ld determine EI_ABIVERSION?

   When we build a dynamic ELF object on Linux, we should always pass
   -lc to it. ld can get EI_ABIVERSION from libc.so.

I think it's bogus to make ld treat libc specially.  It should be
logically possible to build a dynamic executable which does not depend
on libc.

Also, one of the more logical uses for EI_ABIVERSION would be for
statically linked binaries, since they don't get to adapt to the
system using dynamic linking.

   >    5. The dynamic linker will check both EI_OSABI and EI_ABIVERSION when
   >    choosing which shared library to load. With that, we can have both 2
   >    libc.so.6 with different EI_ABIVERSIONs in different directories.
   > 
   > Why would we want such a thing?
   > 
   > How precisely will this approach help with groff?
   > 
   > I think we have a problem with using multiple libraries which are
   > linked against different versions of libc.  However, I don't see how
   > EI_OSABI and EI_ABIVERSION can help with that.
   > 
   > We already have two library versioning schemes: DT_SONAME, and symbol
   > versioning.  Why do we need a third?  What deficiency in the existing
   > schemes does it address?

   We may want to load a different libc.so.6 depending on the C++/C ABI
   version. For groff, on glibc 2.1, we want

   # ldd /usr/bin/groff
	   libstdc++.so.2.8 => /usr/lib/libstdc++.so.2.8 (0x40007000)
	   libm.so.6 => /usr/glibc-2.0/lib/libm.so.6 (0x4004c000)
	   libc.so.6 => /usr/glibc-2.0/libc.so.6 (0x40065000)
	   /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

I don't understand why this is an answer to my question.

Ian

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-16 18:10       ` H.J. Lu
  1998-08-16 18:32         ` Ian Lance Taylor
@ 1998-08-17 13:14         ` Ulrich Drepper
  1998-08-18  7:40           ` H.J. Lu
  1 sibling, 1 reply; 16+ messages in thread
From: Ulrich Drepper @ 1998-08-17 13:14 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Ian Lance Taylor, gas2, libc-hacker

hjl@lucon.org (H.J. Lu) writes:

> 1. Add switchs to ld to set EI_OSABI and EI_ABIVERSION.
> 2. For Linux, set EI_ABIVERSION with C ABI and C++ ABI.

You misunderstand the concept of EI_OSABI.  This ABI is the ELF ABI.
This has nothing to do with any versioning of any other part of the
system.

E.g., HP has ELFOSABI_HPUX because they've invented a few extensions
to the standard SysV ELF which is publically documented.  If they
wouldn't have this EI_OSABI thing a ld.so which is not written by HP
but conforms with the ELF ABI could try to load such a binary and
fail.

This feature is missing in the original ELF approach and you are right
that we need to get a version.  But this will probably be ELFOSABI_GNU
since the ABI will be the same on Linux and Hurd and ...  I expect
Solaris to also get a version since their versioning extensions are
also not 100% ELF compatible.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-17 13:14         ` Ulrich Drepper
@ 1998-08-18  7:40           ` H.J. Lu
  1998-08-18  8:04             ` Ulrich Drepper
  0 siblings, 1 reply; 16+ messages in thread
From: H.J. Lu @ 1998-08-18  7:40 UTC (permalink / raw)
  To: drepper; +Cc: ian, gas2, GNU C Library

> 
> hjl@lucon.org (H.J. Lu) writes:
> 
> > 1. Add switchs to ld to set EI_OSABI and EI_ABIVERSION.
> > 2. For Linux, set EI_ABIVERSION with C ABI and C++ ABI.
> 

I have sent in a patch for glibc 2.1. It should fix the groff problem.
Ulrich, have you looked at it?

Thanks.

H.J.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Has anyone looked at ELF 4.1?
  1998-08-18  7:40           ` H.J. Lu
@ 1998-08-18  8:04             ` Ulrich Drepper
  0 siblings, 0 replies; 16+ messages in thread
From: Ulrich Drepper @ 1998-08-18  8:04 UTC (permalink / raw)
  To: H.J. Lu; +Cc: ian, gas2, GNU C Library

hjl@lucon.org (H.J. Lu) writes:

> I have sent in a patch for glibc 2.1. It should fix the groff problem.
> Ulrich, have you looked at it?

Not yet.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~1998-08-18  8:04 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-08-08  7:20 Has anyone looked at ELF 4.1? H.J. Lu
1998-08-08 10:02 ` Ulrich Drepper
1998-08-08 23:43   ` H.J. Lu
1998-08-10 13:51 ` Ian Lance Taylor
1998-08-10 16:54   ` H.J. Lu
1998-08-11  0:51     ` Roland McGrath
1998-08-11  9:22     ` Ian Lance Taylor
1998-08-16 18:10       ` H.J. Lu
1998-08-16 18:32         ` Ian Lance Taylor
1998-08-16 19:30           ` H.J. Lu
1998-08-16 20:01             ` Ian Lance Taylor
1998-08-17 13:14         ` Ulrich Drepper
1998-08-18  7:40           ` H.J. Lu
1998-08-18  8:04             ` Ulrich Drepper
1998-08-11  0:51   ` Roland McGrath
1998-08-11 20:43     ` Geoff Keating

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).