My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

I haven't heard any feedbacks about my proposal for the libgcc runtime
ABI:

http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00117.html

But I think the current situation is quite broken. In glibc, we have

---
/* This must match what's in frame.h in gcc. How can one do that? */
struct object
{
  void *pc_begin;
  void *pc_end;
  void *fde_begin;
  void *fde_array;
  __SIZE_TYPE__ count;
  struct object *next;
};
---

in elf/soinit.c. In gcc, we have

---
      /* This must match what's in frame.h.  */
      fprintf (stream, "struct object {\n");
      fprintf (stream, "  void *pc_begin;\n");
      fprintf (stream, "  void *pc_end;\n");
      fprintf (stream, "  void *fde_begin;\n");
      fprintf (stream, "  void *fde_array;\n");
      fprintf (stream, "  __SIZE_TYPE__ count;\n");
      fprintf (stream, "  struct object *next;\n");
      fprintf (stream, "};\n");
---

in gcc/collect2.c. However, in gcc/frame.h, there are

struct object {
#ifdef IA64_UNWIND_INFO
  void *pc_base;        /* This field will be set by find_fde. */
#endif
  void *pc_begin;
  void *pc_end;
  struct dwarf_fde *fde_begin;
#ifdef IA64_UNWIND_INFO
  struct dwarf_fde *fde_end;
#endif
  struct dwarf_fde **fde_array;
  size_t count;
  struct object *next;
};

So as of today, the ia64 gcc/glibc are broken due to the mismatch in
struct object. My libgcc runtime ABI proposal will fix it as well
as lead to a fix for the original problem. It means gcc can change
the implementation of

---runtime.h---
#ifndef __RUNTIME_H
#define __RUNTIME_H 1

struct frame_object
{
  /* It should be large enough for future expansion. */
  void * dummy [16];
};

/* Note the following routines are exported interfaces from libgcc; do
   not change these interfaces.  Instead create new interfaces.  Also
   note references to these functions may be made weak in files where
   they are referenced.  */

extern void __register_frame (void * );
extern void __register_frame_table (void *);
extern void __deregister_frame (void *);

/* Called either from crtbegin.o or a static constructor to register the
   unwind info for an object or translation unit, respectively.  */

extern void __register_frame_info (void *, struct frame_object *);

/* Similar, but BEGIN is actually a pointer to a table of unwind
   entries for different translation units.  Called from the file
   generated by collect2.  */

extern void __register_frame_info_table (void *, struct frame_object *);

/* Called from crtend.o to deregister the unwind info for an object.  */

extern void *__deregister_frame_info (void *);

#endif /* __RUNTIME_H */
---

as long as we don't change the ABI defined in runtime.h.

Thanks.


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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Date: Mon, 10 Jul 2000 08:03:57 -0700
   From: "H . J . Lu" <hjl@valinux.com>

   I haven't heard any feedbacks about my proposal for the libgcc runtime
   ABI:

   http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00117.html

   But I think the current situation is quite broken.

Indeed it is.  And apparently people aren't very eager to do something
about it.  The fact that your "proposal" isn't really shocking might
have something to do with it.  Let me explain.  The ABI you're
proposing does already exist.  Changing `sizeof (struct object)' or
changing the calling convention of the functions mentioned in your
runtime.h isn't possible anymore for supported targets with working
exception support in gcc 2.95 or egcs 1.0.3 or so (and has indeed been
impossible for quite a while now for some of those targets).  So
you're either just trying to formalize things, which is fine with me,
or you're proposing something that cannot be done.

Adding a new ABI without continued support for the old one isn't
possible either unless you want to force people to recompile
everything with the new gcc.

On Linux (and the Hurd) the problem is even worse.  Since the frame
info registration functions are present in libc.so, you cannot simply
add a new ABI without forcing everybody to patch and recompile libc.
If we plan ahead it is certainly possible to ease the pain
considerably, but this requires a lot of cooperation between the glibc
and GCC teams, and depending on the solution that's chosen, probably
quite a bit of time (in the order of months).  If this isn't done,
deploying GCC 3.0 on Linux will become a terrible nightmare.

I'm having some problems with "libgcc runtime ABI".  Right now libgcc
is a pile of junk that contains some basic support functions (e.g. for
long long and floating point arithmetic), the exception handling stuff
(both registration of EH frame info, and the language independent EH
runtime stuff), and some sort of C++ runtime (operator new, rtti,
etc.).  Your proposal is at best a specification of the "libgcc EH
frame info registration ABI".

In that respect, the name "runtime.h" seems not very appropriate to
me.

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Mon, Jul 10, 2000 at 07:55:51PM +0200, Mark Kettenis wrote:
>    Date: Mon, 10 Jul 2000 08:03:57 -0700
>    From: "H . J . Lu" <hjl@valinux.com>
> 
>    I haven't heard any feedbacks about my proposal for the libgcc runtime
>    ABI:
> 
>    http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00117.html
> 
>    But I think the current situation is quite broken.
> 
> Indeed it is.  And apparently people aren't very eager to do something
> about it.  The fact that your "proposal" isn't really shocking might
> have something to do with it.  Let me explain.  The ABI you're
> proposing does already exist.  Changing `sizeof (struct object)' or
> changing the calling convention of the functions mentioned in your
> runtime.h isn't possible anymore for supported targets with working
> exception support in gcc 2.95 or egcs 1.0.3 or so (and has indeed been
> impossible for quite a while now for some of those targets).  So
> you're either just trying to formalize things, which is fine with me,
> or you're proposing something that cannot be done.
> 
> Adding a new ABI without continued support for the old one isn't
> possible either unless you want to force people to recompile
> everything with the new gcc.
> 
> On Linux (and the Hurd) the problem is even worse.  Since the frame
> info registration functions are present in libc.so, you cannot simply
> add a new ABI without forcing everybody to patch and recompile libc.
> If we plan ahead it is certainly possible to ease the pain
> considerably, but this requires a lot of cooperation between the glibc
> and GCC teams, and depending on the solution that's chosen, probably
> quite a bit of time (in the order of months).  If this isn't done,
> deploying GCC 3.0 on Linux will become a terrible nightmare.

It is too late now.

> 
> I'm having some problems with "libgcc runtime ABI".  Right now libgcc
> is a pile of junk that contains some basic support functions (e.g. for
> long long and floating point arithmetic), the exception handling stuff
> (both registration of EH frame info, and the language independent EH
> runtime stuff), and some sort of C++ runtime (operator new, rtti,
> etc.).  Your proposal is at best a specification of the "libgcc EH
> frame info registration ABI".
> 
> In that respect, the name "runtime.h" seems not very appropriate to
> me.
> 

My libgcc runtime ABI is the first step to address all of your
concerns. The reason I choose "runtime.h" is a libgcc.so will be
built from libgcc.a. I'd like to have a header file to describe
the exported functions in libgcc.so. Most of the functions in
libgcc are internal to compiler. But the ones listed in "runtime.h"
are also used by glibc and collect2. In any case, the name of the
header file is not important here.

Once we define an exported ABI for libgcc, we can build a libgcc.so
knowing that any binaries linked with libgcc.so using the exported
ABI will work as long as libgcc.so conforms to the libgcc ABI.

I don't think gcc should build libgcc.so at all. It should be the
part of glibc or any system C libraries which use libgcc. When we
build glibc, we can do

# ld -shared -soname libgcc.so.3 \
	-o libgcc-`gcc -dumpversion`.so ... \
	--whole-archive `gcc -print-libgcc-file-name`

We can install libgcc-`gcc -dumpversion`.so under /lib and have
libgcc.so under /usr/lib. We can even make libgcc.so a linker
script:

---
GROUP ( /lib/libgccc.so.3 /usr/lib/libgcc_nonshared.a )
---

where /usr/lib/libgcc_nonshared.a contains the portion of basic support
functions in libgcc.a. We then link libgcc.so with libc.so instead of
libgcc.a. Now we have moved all the libgcc funtions from libc.so to
libgcc.so. I think we can make it to work.



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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Henderson]

On Mon, Jul 10, 2000 at 11:44:52AM -0700, H . J . Lu wrote:
> I don't think gcc should build libgcc.so at all. It should be the
> part of glibc or any system C libraries which use libgcc.

I disagree entirely. 

I think libgcc should be its own thing and its own thing alone.
We need to get glibc out of the business of providing libgcc
functions.  The best long-term way to do that, IMO, is once
libgcc.so exists, have libc.so reference it as DT_AUXILIARY.
That will provide for all backward compatibility wrt the symbols
glibc currently exports.



r~

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Mon, Jul 10, 2000 at 03:34:40PM -0700, Richard Henderson wrote:
> On Mon, Jul 10, 2000 at 11:44:52AM -0700, H . J . Lu wrote:
> > I don't think gcc should build libgcc.so at all. It should be the
> > part of glibc or any system C libraries which use libgcc.
> 
> I disagree entirely. 
> 
> I think libgcc should be its own thing and its own thing alone.

I agree libgcc.so should work with all gccs which conform to the
libgcc.so ABI.

> We need to get glibc out of the business of providing libgcc
> functions.  The best long-term way to do that, IMO, is once

glibc shouldn't provide any libgcc functions. However, glibc will
use some libgcc functions. That means libgcc.so has to be available
when libc.so is loaded. I only proprose to let glibc decide where to
put libgcc.so. gcc only provides a libgcc.a compiled with -fPIC and
maybe a script like build-libgcc.so which will build libgcc.so from
libgcc.a. Glibc will build libgcc.so from libgcc.a in gcc and install
it at an appropriate place.


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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Date: Mon, 10 Jul 2000 15:34:40 -0700
   From: Richard Henderson <rth@twiddle.net>

   On Mon, Jul 10, 2000 at 11:44:52AM -0700, H . J . Lu wrote:
   > I don't think gcc should build libgcc.so at all. It should be the
   > part of glibc or any system C libraries which use libgcc.

   I disagree entirely. 

It's certainly the GCC people who should control the libgcc.so ABI.
And since a libgcc.so upgrade may be necessary when a new compiler is
release, it's probably GCC that should install it.  By all means it
should be a "servicable component"; something you can upgrade without
the need for upgrading all system C libraries with it.

   I think libgcc should be its own thing and its own thing alone.
   We need to get glibc out of the business of providing libgcc
   functions.  The best long-term way to do that, IMO, is once
   libgcc.so exists, have libc.so reference it as DT_AUXILIARY.
   That will provide for all backward compatibility wrt the symbols
   glibc currently exports.

The key word here is "long-term".  Until we are in the situation you
describe any significant changes to the frame info registration
interface will cause serious binary compatibility problems on Linux.
By the time of the next major GCC release ships (presumably with the
frame registration functions in a shared library that's installed in
/lib on most systems), we should have verified that something like the
DT_AUXILIARY thing indeed works.  You cannot say two months before the
GCC 3.0 release "oh yeah, we were going to turn libgcc into a shared
library, let's do it now" and expect things to work right away.
Therefore planning on what to put in libgcc.so should start ASAP.

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Date: Mon, 10 Jul 2000 16:15:28 -0700
   From: "H . J . Lu" <hjl@valinux.com>

   On Mon, Jul 10, 2000 at 03:34:40PM -0700, Richard Henderson wrote:
   > We need to get glibc out of the business of providing libgcc
   > functions.  The best long-term way to do that, IMO, is once

   glibc shouldn't provide any libgcc functions. However, glibc will
   use some libgcc functions. That means libgcc.so has to be available
   when libc.so is loaded. I only proprose to let glibc decide where to
   put libgcc.so. gcc only provides a libgcc.a compiled with -fPIC and
   maybe a script like build-libgcc.so which will build libgcc.so from
   libgcc.a. Glibc will build libgcc.so from libgcc.a in gcc and install
   it at an appropriate place.

This isn't necessary at all.  The shared libgcc belongs in /lib.  If
the GCC folks do their job properly, and take care of backwards
compatibility issues, installing GCC can simply upgrade it if the
version provided with the new GCC has the highest "version number".

Lettenig glibc build libgcc.so from an archive installed by GCC is
pointless and only puts limits on one's possibilities to use nice
hacks.

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

Mark Kettenis <kettenis@wins.uva.nl> writes:

> we should have verified that something like the DT_AUXILIARY thing
> indeed works.

I don't think there is much danger here.  I'm quite sure it works and
if not, I can fix it easily.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

Mark Kettenis <kettenis@wins.uva.nl> writes:

> This isn't necessary at all.  The shared libgcc belongs in /lib.  If
> the GCC folks do their job properly, and take care of backwards
> compatibility issues, installing GCC can simply upgrade it if the
> version provided with the new GCC has the highest "version number".

Letting it all to the gcc folks has one major drawback: they will
either have to keep track of ABI changes for every single
architecture/OS combination or they will have to bump the version
number whenever something changed on any of the supported platforms.
The latter has the concequences that after a while you'l have dozends
of libgcc.so of which you cannot remove a single one unless you are
making sure everything is recompiled.  This latter approach will never
get my blessing but of course I cannot prevent the gcc people from
making this mistake.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Sender: drepper@cygnus.com
   Cc: rth@twiddle.net, hjl@valinux.com, libc-hacker@sourceware.cygnus.com,
      gcc@gcc.gnu.org
   Reply-To: drepper@cygnus.com (Ulrich Drepper)
   X-fingerprint: BE 3B 21 04 BC 77 AC F0  61 92 E4 CB AC DD B9 5A
   From: Ulrich Drepper <drepper@redhat.com>
   Date: 10 Jul 2000 17:04:50 -0700
   Content-Type: text/plain; charset=US-ASCII

   Mark Kettenis <kettenis@wins.uva.nl> writes:

   > we should have verified that something like the DT_AUXILIARY thing
   > indeed works.

   I don't think there is much danger here.  I'm quite sure it works and
   if not, I can fix it easily.

I wasn't really questioning whether DT_AUXILIARY worked.  I'm worried
if the little schemes that we all think up here will work in the real
world, when people start mixing shared libraries and programs produced
by different compilers.  That was the big problem with the
__register_frame_info mess.  IMHO we have to allow for an extended
period of testing.

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Henderson]

On Tue, Jul 11, 2000 at 02:15:17AM +0200, Mark Kettenis wrote:
> I wasn't really questioning whether DT_AUXILIARY worked.  I'm worried
> if the little schemes that we all think up here will work in the real
> world, when people start mixing shared libraries and programs produced
> by different compilers.

I have verified on a smaller test case that DT_AUXILIARY does what we
want wrt symbol resolution with legacy applications.

> IMHO we have to allow for an extended period of testing.

Indeed.  I've been having good intentions toward getting this taken
care of for quite some time.  The barrier is the amount of horror I
feel in trying to figure out libtool in a (canadian) cross environment.

But it ought to get done soon...



r~

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Joern Rennecke]

> Letting it all to the gcc folks has one major drawback: they will
> either have to keep track of ABI changes for every single
> architecture/OS combination or they will have to bump the version
> number whenever something changed on any of the supported platforms.
> The latter has the concequences that after a while you'l have dozends
> of libgcc.so of which you cannot remove a single one unless you are
> making sure everything is recompiled.  This latter approach will never
> get my blessing but of course I cannot prevent the gcc people from
> making this mistake.

I suppose we could have a target macro for the libgcc.so version number
that gets bumped up whenever the ABI changes.
Simultanously, there'd be a version number for libgcc2.c to keep
track of new and changed functions.  The build mechanism will then
select the higher number for libgcc.so

Whoever the version number is bumped up for a target you have to use
a number that is lager than the current libgcc2 number, and you have to
update a comment next to the libgcc version number what the next number
should be, unless there is already a larger number there.

Or we could be lazy and use a major / minor number scheme for abi / libgcc2.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

Joern Rennecke <amylaar@cygnus.co.uk> writes:

> Or we could be lazy and use a major / minor number scheme for abi / libgcc2.

No, this won't work.  ELF has no understanding of minor versions.

You'll have to keep track of the ABI numbering.  What you don't have
to do is bump the version number for every newly added interface.
This is no problem and should be taken care of using versioning.  But
you'll have to bump the number for each and every actual change.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Zack Weinberg]

On Mon, Jul 10, 2000 at 05:48:05PM -0700, Richard Henderson wrote:
> 
> Indeed.  I've been having good intentions toward getting this taken
> care of for quite some time.  The barrier is the amount of horror I
> feel in trying to figure out libtool in a (canadian) cross environment.

I ask again, why do we need libtool?  What supported platform cannot
be handled by teaching the Makefile the magic switches to pass to the
compiler and linker?

zw

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Mon, Jul 10, 2000 at 05:58:09PM -0700, Ulrich Drepper wrote:
> Joern Rennecke <amylaar@cygnus.co.uk> writes:
> 
> > Or we could be lazy and use a major / minor number scheme for abi / libgcc2.
> 
> No, this won't work.  ELF has no understanding of minor versions.
> 
> You'll have to keep track of the ABI numbering.  What you don't have
> to do is bump the version number for every newly added interface.
> This is no problem and should be taken care of using versioning.  But
> you'll have to bump the number for each and every actual change.
> 

That is another reason why I prefer glibc builds libgcc.so from
libgcc.a provided by gcc. Glibc has all the infrastructure needed
to do it. I doubt it will be easy for gcc to do the same. Besides
only very few OSes are affected by this. Why does gcc have to bother
with it? It will be very hard for gcc to do it right for every target.
IMHO, gcc should only provide a stable libgcc ABI and leave libgcc.so
to each affected target.


H.J.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jeffrey A Law]

  In message < m3k8etle7z.fsf@otr.mynet.cygnus.com >you write:
  > Mark Kettenis <kettenis@wins.uva.nl> writes:
  > 
  > > This isn't necessary at all.  The shared libgcc belongs in /lib.  If
  > > the GCC folks do their job properly, and take care of backwards
  > > compatibility issues, installing GCC can simply upgrade it if the
  > > version provided with the new GCC has the highest "version number".
  > 
  > Letting it all to the gcc folks has one major drawback: they will
  > either have to keep track of ABI changes for every single
  > architecture/OS combination or they will have to bump the version
  > number whenever something changed on any of the supported platforms.
  > The latter has the concequences that after a while you'l have dozends
  > of libgcc.so of which you cannot remove a single one unless you are
  > making sure everything is recompiled.  This latter approach will never
  > get my blessing but of course I cannot prevent the gcc people from
  > making this mistake.
What would you recommend then?  Considering that we can not tie GCC to glibc
since GCC is used on a lot of systems that do not use glibc?

We're certainly open to suggestions -- a shared libgcc has a number of nasty
problems that need solving (but it also solves a huge number of nasty problems
that we've had over the years).

jeff

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

Jeffrey A Law <law@cygnus.com> writes:

> What would you recommend then?  Considering that we can not tie GCC to glibc
> since GCC is used on a lot of systems that do not use glibc?

I don't really know what to do, I haven't spend much time thinking
about it.  Your comment above is exactly amplifying my fear: gcc
people cannot spend so many thoughts on one platform.  Naturally, I
don't blame you.

This is exactly why HJ suggested to leve the generation of the
libgcc.so to glibc or some additional new package.  If gcc provides
simply the libgcc with the interface(s) it currently supports the
creation of libgcc.so outside gcc (which therefore can have many more
demands on the environment like a ld which understands versioning) can

- add more legacy interface which are needed but are not supported
  anymore by gcc or which do some data rewriting before calling the
  actual libgcc functions

- create and install the actual libgcc.so with the appropriate soname


The alternative is to find somebody (or a group) for each of the
arch/OS combinations which care about compatibility at this level and
have them maintain the data inside gcc and to significantly extend the
build infrastructure to handle the soname and versioning requirements.

Everybody who just dismissed HJ's proposal should stop and think about
this for a moment.  Will you be willing to do what I described inside
gcc?


How this actually should be implemented is unclear to me.  It might be
that the solution is a small shell script and possibly a few more .c
files and create from the installed libgcc.a a .so file.  It's also
possible to pass a lot more information inside the libgcc.a file
(remember: this is an archive and not at all limited to .o files).  So
it would be possible to put into libgcc.a all the sources and some
kind of interface description.

This certainly requires some more discussion and somebody with time to
really think it through.  HJ already made a proposal so we need to
investigate it.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> glibc shouldn't provide any libgcc functions. However, glibc will
> use some libgcc functions. That means libgcc.so has to be available
> when libc.so is loaded. I only proprose to let glibc decide where to
> put libgcc.so. gcc only provides a libgcc.a compiled with -fPIC and
> maybe a script like build-libgcc.so which will build libgcc.so from
> libgcc.a. Glibc will build libgcc.so from libgcc.a in gcc and install
> it at an appropriate place.

Does that mean users have to rebuilt glibc whenever they install a new
version of gcc?

Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> Everybody who just dismissed HJ's proposal should stop and think about
> this for a moment.  Will you be willing to do what I described inside
> gcc?

What I fail to see is why gcc can't ship with the mechanisms required
for a certain target. Some target expert has to know the required
mechanism, right. Why can't that specific expert put the mechanism
into gcc? In many cases, she'd have to convince gcc maintainers that
this is indeed a target problem, and that it is indeed a sane solution
to that problem - but if it is an obviously correct solution, the
patch will be accepted. 

Perhaps the target expert isn't too familiar with gcc sources. In that
case, she can get help on gcc@gcc.gnu.org.

> This certainly requires some more discussion and somebody with time to
> really think it through.  HJ already made a proposal so we need to
> investigate it.

If his proposal was to provide a -fPIC libgcc object file collection
which is transformed into a shared library during glibc installation -
that won't work. I don't think users will want to rebuild glibc as
part of gcc installation.

Also, I'd rather see the magic that glibc installation would do be
performed as part of gcc installation, instead of perhaps being a
glibc-provided script that has this magic.

Regards,
Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Henderson]

On Mon, Jul 10, 2000 at 06:10:55PM -0700, Zack Weinberg wrote:
> I ask again, why do we need libtool?  What supported platform cannot
> be handled by teaching the Makefile the magic switches to pass to the
> compiler and linker?

We don't, necessarily.  But make in general doesn't have complex
macro expansion.  Which implies we'll have to have some sort of
script-y thing.  Either that or leave the entire library target
in the target makefile fragment.


r~

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:

> Perhaps the target expert isn't too familiar with gcc sources. In that
> case, she can get help on gcc@gcc.gnu.org.

The problem is that this is causing much more pain than necessary.
Adding something to gcc is hard.  There are so many things to take
care of since so many files are shared by many architecture.
Standaline packages don't have this problem.

> If his proposal was to provide a -fPIC libgcc object file collection
> which is transformed into a shared library during glibc installation -
> that won't work. I don't think users will want to rebuild glibc as
> part of gcc installation.

I don't think this works either.  This is my I'm currently favouring a
standaline package.  But there might be situation where a new libc
might require a new version of the libgcc.so and therefore there must
be some kind of coupling between this new package and glibc.  Perhaps
something like an add-on (in the glibc-sense) which can also be used
standalone).

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Tue, Jul 11, 2000 at 12:51:24AM -0700, Ulrich Drepper wrote:
> > If his proposal was to provide a -fPIC libgcc object file collection
> > which is transformed into a shared library during glibc installation -
> > that won't work. I don't think users will want to rebuild glibc as
> > part of gcc installation.
> 
> I don't think this works either.  This is my I'm currently favouring a
> standaline package.  But there might be situation where a new libc
> might require a new version of the libgcc.so and therefore there must
> be some kind of coupling between this new package and glibc.  Perhaps
> something like an add-on (in the glibc-sense) which can also be used
> standalone).
 
A standalone package, which can also be used as a glibc add-on, seems
a reasonable solution. That will be target specific.

I have to remind everyone that we have to have a stable, reasonable
libgcc runtime ABI before we can build libgcc.so. We have to support
any ABI functions forever. It doesn't mean gcc has to support the
old ABI functions directly. But the standalone package has to. It
has to be able to find a way to support old ABI functions somehow.
We can do many things under Linux. But we still need some support
from gcc.

I am thinking libgcc.so may look like

GROUP (/lib/libgcc.so /usr/lib/libgcc_nonshared.a)

where /lib/libgcc.so only contains libgcc funtions which can only have
one copy cross the executable and all DSOs. We should identify tham
first.


H.J.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jeffrey A Law]

  In message < m366qdl2ar.fsf@otr.mynet.cygnus.com >you write:
  > I don't really know what to do, I haven't spend much time thinking
  > about it.  Your comment above is exactly amplifying my fear: gcc
  > people cannot spend so many thoughts on one platform.  Naturally, I
  > don't blame you.
  > 
  > This is exactly why HJ suggested to leve the generation of the
  > libgcc.so to glibc or some additional new package.
This seems totally backwards to me.  GCC knows about things like it's
install directory, what version # to use for libgcc, what libraries have
been built (do you really want to spread multilib knowledge any further
than it's already spread)?

We should handle this like we do any other problem in GCC by designing a
system that is relatively generic and which can be easily tweaked to deal
with system specific dependencies.

I do not see what we gain by moving the creation of libgcc.so to another
package other than unnecessary complexity.  I do not see that it simplifies
things.

  > simply the libgcc with the interface(s) it currently supports the
  > creation of libgcc.so outside gcc (which therefore can have many more
  > demands on the environment like a ld which understands versioning) can
But that can be done in gcc too -- ie, we have code which knows that 
ld understands versioning and some backup plan where ld does not understand
versioning.

We have autoconf see what version of ld you've got and the appropriate code
is automatically enabled.

  > - add more legacy interface which are needed but are not supported
  >   anymore by gcc or which do some data rewriting before calling the
  >   actual libgcc functions
Agreed, if you're going to do this then I'd like to see it happen completely
outside gcc.  I'm not sure how wise it is, but if we provide both libgcc.a
and libgcc.so, you'll still have this capability.

  > - create and install the actual libgcc.so with the appropriate soname
What about moving this into a different package makes it easier than having
it in gcc?  I'm thinking about install paths, multilibs and the like -- GCC
knows about that stuff, and I'm not keen on expanding the number of packages
that need to know about such braindamage.


  > The alternative is to find somebody (or a group) for each of the
  > arch/OS combinations which care about compatibility at this level and
  > have them maintain the data inside gcc and to significantly extend the
  > build infrastructure to handle the soname and versioning requirements.
Yup.  That's how things have always been done in gcc-land.  

  > Everybody who just dismissed HJ's proposal should stop and think about
  > this for a moment.  Will you be willing to do what I described inside
  > gcc?
Yes.

  > How this actually should be implemented is unclear to me.  It might be
  > that the solution is a small shell script and possibly a few more .c
  > files and create from the installed libgcc.a a .so file.  It's also
  > possible to pass a lot more information inside the libgcc.a file
  > (remember: this is an archive and not at all limited to .o files).  So
  > it would be possible to put into libgcc.a all the sources and some
  > kind of interface description.
Yup.  You can hide all kinds of interesting things in .a files.  But is
that really a good idea?  Presumably you're looking at this as a way to
pass information from gcc to some external package which builds the
shared library.  However, if we build the shared library within gcc itself
I'm not sure if we need to squirrel away random information in libgcc.a.

jeff

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> I don't think this works either.  This is my I'm currently favouring a
> standaline package.  But there might be situation where a new libc
> might require a new version of the libgcc.so and therefore there must
> be some kind of coupling between this new package and glibc.  Perhaps
> something like an add-on (in the glibc-sense) which can also be used
> standalone).

What exactly would this package do? Before somebody goes off and
writes a new tool I'd be curious as to that tool should do. Perhaps
work can be saved by finding that the same effect can be achieved with
less effort.

Regards,
Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

Jeffrey A Law <law@cygnus.com> writes:

> This seems totally backwards to me.  GCC knows about things like it's
> install directory,

Right here you are wrong.  The libgcc.so must never ever installed in
a gcc-specific directory.  Just think about what this would mean.

> what version # to use for libgcc,

This implies you are willing to track the version numbers for all the
different target.  Again, my argument is that you are *not* able to do
this accurately since you cannot effort spending that much time on it.

> what libraries have been built (do you really want to spread
> multilib knowledge any further than it's already spread)?

We are not talked about some stupid embedded systems with multilib
needs.  We are talking about systems where we need binary
compatibility because of shared libraries.

If you want to extend this to other, e.g., embedded systems, for
whatever reason you can device another scheme since it will not have
the same requirement.

> I do not see what we gain by moving the creation of libgcc.so to another
> package other than unnecessary complexity.  I do not see that it simplifies
> things.

Then you really misunderstood the motifs.

> But that can be done in gcc too

I don't doubt this but will you have the manpower to keep this up?
Because this is supposed to run on Linux where we use all kinds of
features (for example its currently talked about using the libgcc.so
in a DT_AUXILIARY entry).

>   > - add more legacy interface which are needed but are not supported
>   >   anymore by gcc or which do some data rewriting before calling the
>   >   actual libgcc functions
> Agreed, if you're going to do this then I'd like to see it happen completely
> outside gcc.  I'm not sure how wise it is, but if we provide both libgcc.a
> and libgcc.so, you'll still have this capability.

So you basically already agree that the work has to be done outside gcc.

> 
>   > - create and install the actual libgcc.so with the appropriate soname
> What about moving this into a different package makes it easier than having
> it in gcc?  I'm thinking about install paths, multilibs and the like -- GCC
> knows about that stuff, and I'm not keen on expanding the number of packages
> that need to know about such braindamage.

Again, multilibs are uninteresting.  The install directory will be
/lib on Linux and similar directories for other systems.

>   > The alternative is to find somebody (or a group) for each of the
>   > arch/OS combinations which care about compatibility at this level and
>   > have them maintain the data inside gcc and to significantly extend the
>   > build infrastructure to handle the soname and versioning requirements.
> Yup.  That's how things have always been done in gcc-land.  

But I don't believe this will work.  It didn't work so far.

>   > Everybody who just dismissed HJ's proposal should stop and think about
>   > this for a moment.  Will you be willing to do what I described inside
>   > gcc?
> Yes.

You have to show me it works before I believe it.

> Yup.  You can hide all kinds of interesting things in .a files.  But is
> that really a good idea?  Presumably you're looking at this as a way to
> pass information from gcc to some external package which builds the
> shared library.

Right.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jeffrey A Law]

  In message < m3bt04k58c.fsf@otr.mynet.cygnus.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > > This seems totally backwards to me.  GCC knows about things like it's
  > > install directory,
  > 
  > Right here you are wrong.  The libgcc.so must never ever installed in
  > a gcc-specific directory.  Just think about what this would mean.
Yes, I'd forgotton about that.  It's one of the issues that needs to
be addressed.  However, I'm not going to say "must never", just that it's
an issues that must be resolved in one way or another.

  > 
  > > what version # to use for libgcc,
  > 
  > This implies you are willing to track the version numbers for all the
  > different target.  Again, my argument is that you are *not* able to do
  > this accurately since you cannot effort spending that much time on it.
But we need to -- we're not just building a linux compiler.  We need this
capability across a number of systems to resolve a number of nasty problems.

Punting it to an external package is just that -- punting.


  > > what libraries have been built (do you really want to spread
  > > multilib knowledge any further than it's already spread)?
  > 
  > We are not talked about some stupid embedded systems with multilib
  > needs.  We are talking about systems where we need binary
  > compatibility because of shared libraries.
Some native systems have multilibs.  alphas for example, maybe sparcs.
And in the embedded linux world we will likely have systems that need
multilibs.  We can't simply ignore those issues.


  > >   > - add more legacy interface which are needed but are not supported
  > >   >   anymore by gcc or which do some data rewriting before calling the
  > >   >   actual libgcc functions
  > > Agreed, if you're going to do this then I'd like to see it happen complet
  > ely
  > > outside gcc.  I'm not sure how wise it is, but if we provide both libgcc.
  > a
  > > and libgcc.so, you'll still have this capability.
  > 
  > So you basically already agree that the work has to be done outside gcc.
No, I said that it is technically possible to do what you want outside
of GCC given what we provide in libgcc.a.  I did _NOT_ say that the
"work has to be done outside gcc".  Far from it.

  > Again, multilibs are uninteresting.  The install directory will be
  > /lib on Linux and similar directories for other systems.
Multilibs are very interesting, and I don't think it's a given that the
install directory will be /lib.  I believe that is still subject to debate.


jeff

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Geoff Keating]

> From: Ulrich Drepper <drepper@redhat.com>
> Date: 11 Jul 2000 09:21:23 -0700

> > what libraries have been built (do you really want to spread
> > multilib knowledge any further than it's already spread)?
> 
> We are not talked about some stupid embedded systems with multilib
> needs.  We are talking about systems where we need binary
> compatibility because of shared libraries.

Actually, libgcc.so needs to be built with the same multilibs as
glibc, not all the ones that gcc supports.  For example, on
powerpc-linux we don't need a -msoft-float libgcc.so because it would
be useless.  So this is knowledge that is presently only held by
glibc.

> If you want to extend this to other, e.g., embedded systems, for
> whatever reason you can device another scheme since it will not have
> the same requirement.

... and even for hosted architectures it's tricky.  For instance, on
AIX we'll have to use the AIX mechanism for putting 32-bit and 64-bit
objects in the same shared library, which will be completely different
to anything done elsewhere.  For HPUX, there will be another
completely different thing to support o32/n32/n64 (or whatever it is).

> > I do not see what we gain by moving the creation of libgcc.so to another
> > package other than unnecessary complexity.  I do not see that it simplifies
> > things.
> 
> Then you really misunderstood the motifs.
> 
> > But that can be done in gcc too
> 
> I don't doubt this but will you have the manpower to keep this up?
> Because this is supposed to run on Linux where we use all kinds of
> features (for example its currently talked about using the libgcc.so
> in a DT_AUXILIARY entry).
> 
> >   > - add more legacy interface which are needed but are not supported
> >   >   anymore by gcc or which do some data rewriting before calling the
> >   >   actual libgcc functions
> > Agreed, if you're going to do this then I'd like to see it happen completely
> > outside gcc.  I'm not sure how wise it is, but if we provide both libgcc.a
> > and libgcc.so, you'll still have this capability.

Hey!  This is the whole point of having libgcc.so.  If it's going to
be done outside gcc, then the whole libgcc.so needs to be done outside gcc.

> So you basically already agree that the work has to be done outside gcc.

> >   > The alternative is to find somebody (or a group) for each of the
> >   > arch/OS combinations which care about compatibility at this level and
> >   > have them maintain the data inside gcc and to significantly extend the
> >   > build infrastructure to handle the soname and versioning requirements.
> > Yup.  That's how things have always been done in gcc-land.  
> 
> But I don't believe this will work.  It didn't work so far.

I don't think this will work either.  It's not something that can be
done by a group inside gcc, every maintainer who can change the
affected files must understand the issues.  (At present, that includes
all the target-specific .h files.)

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Tue, Jul 11, 2000 at 10:34:05AM -0600, Jeffrey A Law wrote:
>   In message < m3bt04k58c.fsf@otr.mynet.cygnus.com >you write:
>   > Jeffrey A Law <law@cygnus.com> writes:
>   > 
>   > > This seems totally backwards to me.  GCC knows about things like it's
>   > > install directory,
>   > 
>   > Right here you are wrong.  The libgcc.so must never ever installed in
>   > a gcc-specific directory.  Just think about what this would mean.
> Yes, I'd forgotton about that.  It's one of the issues that needs to
> be addressed.  However, I'm not going to say "must never", just that it's
> an issues that must be resolved in one way or another.
> 

I don't think Linux has much choice. It probably has to be installed
along side with libc.so.

>   > 
>   > > what version # to use for libgcc,
>   > 
>   > This implies you are willing to track the version numbers for all the
>   > different target.  Again, my argument is that you are *not* able to do
>   > this accurately since you cannot effort spending that much time on it.
> But we need to -- we're not just building a linux compiler.  We need this

Look it this way. Since gcc is not a linux specific compiler and
the libgcc/libc issuse is limited to very few targets, why should
gcc spend HUGE amount of time up front and for continuing support?

> capability across a number of systems to resolve a number of nasty problems.

Can you name systems which have the same issue? Maybe we should talk
to them to see what they want to do.

> Punting it to an external package is just that -- punting.
> 
> 
>   > > what libraries have been built (do you really want to spread
>   > > multilib knowledge any further than it's already spread)?
>   > 
>   > We are not talked about some stupid embedded systems with multilib
>   > needs.  We are talking about systems where we need binary
>   > compatibility because of shared libraries.
> Some native systems have multilibs.  alphas for example, maybe sparcs.
> And in the embedded linux world we will likely have systems that need
> multilibs.  We can't simply ignore those issues.

Linux (glibc) has its own multilibs support, for SHARED LIBRARIES, not
just for static libraries. When Ulrich said "multilibs are
uninteresting", I take it meant comparing with the solution for
multilibs SHARED LIBRARIES in glibc, the one in gcc looks dumb if not
stupid.

>   > So you basically already agree that the work has to be done outside gcc.
> No, I said that it is technically possible to do what you want outside
> of GCC given what we provide in libgcc.a.  I did _NOT_ say that the
> "work has to be done outside gcc".  Far from it.
> 

Please keep in mind we are talking DSO here. gcc never has any good
track record on the support for binary compatibility in DSOs. I put in
something called "library interface." But it is not enough for backward
binary compatibility. The glibc's track record is not perfect, but it
is quite good and we have leaned a lot from our experiences.


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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Date: Tue, 11 Jul 2000 10:00:49 -0700
   From: "H . J . Lu" <hjl@valinux.com>

   I don't think Linux has much choice. It probably has to be installed
   along side with libc.so.

It also might have to be installed whenever a new version of GCC is
installed.  In fact that's the only moment a new libgcc.so will have
to be installed apart from bootstrapping the whole scheme.

   >   > 
   >   > > what version # to use for libgcc,
   >   > 
   >   > This implies you are willing to track the version numbers for all the
   >   > different target.  Again, my argument is that you are *not* able to do
   >   > this accurately since you cannot effort spending that much time on it.
   > But we need to -- we're not just building a linux compiler.  We need this

   Look it this way. Since gcc is not a linux specific compiler and
   the libgcc/libc issuse is limited to very few targets, why should
   gcc spend HUGE amount of time up front and for continuing support?

In essence, the issues aren't really a libgcc/libc issue.  Currently
all ELF systems have similar problems with getting exceptions working
in the presence of shared libraries.  Most of the other systems with
shared libraries probably suffer too.

The fact that the Linux libc contains and reexports the frame info
registration functions make things a little more complicated, and
might induce the need for some additional tweaks.  But the problem
isn't Linux-specific by far.

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Tue, Jul 11, 2000 at 07:36:37PM +0200, Mark Kettenis wrote:
> In essence, the issues aren't really a libgcc/libc issue.  Currently
> all ELF systems have similar problems with getting exceptions working
> in the presence of shared libraries.  Most of the other systems with
> shared libraries probably suffer too.
> 
> The fact that the Linux libc contains and reexports the frame info
> registration functions make things a little more complicated, and

I believe it is the cause of the problem. Otherwise, it will be
libstdc++.so who contains and reexports the frame info registration
functions, which is the part of gcc and handled by my "library
interface" scheme. It is an entirely different issuse.

> might induce the need for some additional tweaks.  But the problem
> isn't Linux-specific by far.
> 

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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

Jeffrey A Law <law@cygnus.com> writes:

> Yes, I'd forgotton about that.  It's one of the issues that needs to
> be addressed.  However, I'm not going to say "must never", just that it's
> an issues that must be resolved in one way or another.

Every application will be linked against this library and therefore it
must be available on the root filesystem where there is certainly no
room for gcc.

> But we need to -- we're not just building a linux compiler.  We need this
> capability across a number of systems to resolve a number of nasty problems.

We don't have to care about these things on other platforms (perhaps
on BSD but these people do their own stuff anyway).  The problem only
exists if the libc is using the code from libgcc and possibly
re-exports it.

> Some native systems have multilibs.  alphas for example, maybe sparcs.
> And in the embedded linux world we will likely have systems that need
> multilibs.  We can't simply ignore those issues.

None of the systems we care about.

> Multilibs are very interesting, and I don't think it's a given that the
> install directory will be /lib.  I believe that is still subject to debate.

We are completely missing each other.  You completely underestimate
the work needed to keep this compatibility library up-to-date.
Putting this in gcc means you cannot make a new release of gcc until
every single platform is handled (means, you have to actually review
all the interfaces for each OS/arch combination).  If nobody is
volunteering you have to do it yourself since otherwise you'll put out
a gcc version which can create incompatible binaries or breaks
existing one.  This is wrong.

Doing things outside gcc has the advantage of not delaying the
release.  The worst case is that the new release cannot be used on a
certain platform but that's it.  And this would be the fault of the
people writing the libgcc.so for that arch/OS.

It will also be up to the arch/OS groups to decide when binary
compatibility is dropped and all compatibility stuff from libgcc.so
should be dropped.

In the end you might end up to have an individual configuration for
each arch/OS/host/target combination.  I don't believe for a second
that you can centrally manage this.


I don't know how to make this clearer, libgcc.so is a system library.
Unless you want to get into the system library development you should
not even consider handling the libgcc.so yourself.

Besides, I have not heard a single convincing argument why libgcc.so
should be generate as part of gcc.  What do you want to achieve?

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Date: Mon, 10 Jul 2000 17:48:05 -0700
   From: Richard Henderson <rth@cygnus.com>

   > IMHO we have to allow for an extended period of testing.

   Indeed.  I've been having good intentions toward getting this taken
   care of for quite some time.  The barrier is the amount of horror I
   feel in trying to figure out libtool in a (canadian) cross environment.

   But it ought to get done soon...

I'm certainly willing to put some work into it this summer.  However,
let's not let the urge to see some real code clobber our view on the
bigger picture just yet.  I've just posted an analysis of the contents
of the GCC 2.95.2 libgcc.a to the gcc list.  I hope that can serve as
a guide on exactly what should be put into the shared libgcc.  Let's
first decide on what to put into it before providing the
infrastructure to actually build it.

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   From: Joern Rennecke <amylaar@cygnus.co.uk>
   Date: Tue, 11 Jul 2000 01:52:47 +0100 (BST)

   Whoever the version number is bumped up for a target you have to use
   a number that is lager than the current libgcc2 number, and you have to
   update a comment next to the libgcc version number what the next number
   should be, unless there is already a larger number there.

   Or we could be lazy and use a major / minor number scheme for abi / libgcc2.

I think the version number scheme isn't really an issue.  People don't
seem to get that you cannot remove things from the ABI and/or replace
things in the ABI without causing severe binary compatibility problems
with shared libraries, especially on systems where libc depends on the
shared libgcc.

Suppose you had for a long time a libgcc.so.1, and built several
shared libraries with it.  Now introduce libgcc.so.2 (because you had
to break backwards compatibility for some reason) and start building
programs with it.  These programs cannot use the old shared libraries
since libgcc.so.1 and libgcc.so.2 would probably clash.  Now think of
libc as one of these old shared libraries, and realise that things are
hopelessly hosed.  Recompiling libc won't help in this case, since
that would mean you cannot use any old binaries at all.  This means
you'll have to bump libc's soname, which is something that people
really don't like.

The conclusion is that control over the libgcc.so ABI should be really
tight.  The less stuff it contains the better.

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Linus Torvalds]

Is there something really wrong with just sidestepping this issue
altogether with the following simple rule:

 - libgcc is always statically linked inside the object file that needs
   it (be it a binary or a shared library)

Yes. It will result in code duplication. Is that a huge problem? libgcc
is supposed to be small or non-existent anyway. I know it's bloated at
least right now - but looking at the x86 libgcc I have at least some of
the bloatedness seems to be due to bad coding and bad interfaces.

Wouldn't it be nicer to work on making the thing smaller instead, and
making people happier about just linking it statically? Make it be a
small thing that is hidden away inside gcc's own files, rather than
something that has to care about the shared library scheme of the
particular target architecture..

(Ugh. I looked at __negdi2 on x86. Not pretty. It looks like it should
be

	#ifdef _not_fastcall
		movl 4(%esp),%eax
		movl 8(%esp),%edx
	#endif
		notl %eax
		notl %edx
		addl $1,%eax
		adcl $0,%edx
		ret

instead of the current horror).  That's a whopping 20 bytes or so, which
is probably a lot less than the silly dynamic linking overhead would be
anyway, so "binary size" is not a very good argument for trying to make
this a .so.

Yes, some of them are larger. Not many. And maybe those larger ones
could be standardized well enough that they can be exported entirely
outside gcc and there would be that much less coupling between gcc and
glibc again..

			Linus

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jeffrey A Law]

  In message < 200007111756.e6BHutV26876@delius.kettenis.local >you write:
  > The conclusion is that control over the libgcc.so ABI should be really
  > tight.  The less stuff it contains the better.
No doubt.  The ABI for things in libgcc needs to be rock solid.

jeff

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Joern Rennecke]

> I think the version number scheme isn't really an issue.  People don't
> seem to get that you cannot remove things from the ABI and/or replace
> things in the ABI without causing severe binary compatibility problems
> with shared libraries, especially on systems where libc depends on the
> shared libgcc.

Actually, the same is true without shared libraries, if the users just
want to keep using old .o files (inside or outside of static libraries)
together with ones compiled with a new compiler.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Joern Rennecke]

> Doing things outside gcc has the advantage of not delaying the
> release.  The worst case is that the new release cannot be used on a
> certain platform but that's it.  And this would be the fault of the
> people writing the libgcc.so for that arch/OS.

I think this is a non-issue.  We can control the generation of libgcc.so
by a target macro, so only those targets that are ready to have it
(and where it makes sense to have it to start with) will have it.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Geoff Keating]

> From: Linus Torvalds <torvalds@transmeta.com>
> Date: Tue, 11 Jul 2000 11:45:32 -0700
> Newsgroups: linux.egcs
> 
> Is there something really wrong with just sidestepping this issue
> altogether with the following simple rule:
> 
>  - libgcc is always statically linked inside the object file that needs
>    it (be it a binary or a shared library)
> 
> Yes. It will result in code duplication. Is that a huge problem?

Yes.  There is at least one routine in libgcc that must not be
duplicated; it relies on there being only one copy of itself in the
whole program.  This is the routine causing all the trouble.  We also
occasionally want to modify this routine, and you can't do that if
it's linked statically into every program.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

Joern Rennecke <amylaar@cygnus.co.uk> writes:

> Actually, the same is true without shared libraries, if the users just
> want to keep using old .o files (inside or outside of static libraries)
> together with ones compiled with a new compiler.

In an ideal world, yes, you would allow this.  But in general this is
nothing we can promise.  Only the encapsulation inside a DSO can make
binary compatibility with somewhat changing interfaces a reality.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

Joern Rennecke <amylaar@cygnus.co.uk> writes:

> I think this is a non-issue.  We can control the generation of libgcc.so
> by a target macro, so only those targets that are ready to have it
> (and where it makes sense to have it to start with) will have it.

I was not talking about the first release.  I was talking about the
next one.  Once you introduced the libgcc.so stuff you'll have to keep
it up-to-date and test it.  If something is not sufficiently tested or
updated, the new version might still run fine and people will start
using it, but you created a new ABI.  From that point on you not only
have the provide the ABI of the previous release, you also have to
support the errorneously introduced new ABI since this is what will be
expected.

It would be really advised that before gcc people take up the task of
maintaining ABIs they look into the problems this involves in other
projects.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Linus Torvalds]

On Tue, 11 Jul 2000, Geoff Keating wrote:
> > 
> > Is there something really wrong with just sidestepping this issue
> > altogether with the following simple rule:
> > 
> >  - libgcc is always statically linked inside the object file that needs
> >    it (be it a binary or a shared library)
> > 
> > Yes. It will result in code duplication. Is that a huge problem?
> 
> Yes.  There is at least one routine in libgcc that must not be
> duplicated; it relies on there being only one copy of itself in the
> whole program.  This is the routine causing all the trouble.  We also
> occasionally want to modify this routine, and you can't do that if
> it's linked statically into every program.

Ok. It sounds like that is a special routine, though. Mind if I ask why?
Might it not be better to consider that routine part of the crt0 kind of
startup logic instead of a libgcc?

The downside with the current dynamic libgcc extends past the silly
trouble with interfacing to libc. I wouldn't think that it is unreasonable
to change libgcc semantics in between compiler versions, yet I don't think
it should be impossible to link dynamic libraries compiled with one
compiler against a binary compiled with another.

Right now gcc cannot change the interfaces to the simple libgcc routines,
because gcc doesn't control what libgcc things get linked against. Which
means, for example, that optimizing things like "_cmpsdi2" to use a
non-standard (and saner) calling convention etc is just not possible
without strange and wonderful versioning schemes.

			Linus

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Tue, Jul 11, 2000 at 12:38:04PM -0700, Ulrich Drepper wrote:
> 
> It would be really advised that before gcc people take up the task of
> maintaining ABIs they look into the problems this involves in other
> projects.
> 

Please take Ulrich's word for it. He was speaking from his experiences
maintaining the glibc runtime ABI in such a way that it will work with
all the existing binaries. It is a very difficult task. I don't think
gcc should take it before people know what is involved.


H.J.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Alexandre Oliva]

On Jul 11, 2000, Ulrich Drepper <drepper@redhat.com> wrote:

> Every application will be linked against this library and therefore it
> must be available on the root filesystem where there is certainly no
> room for gcc.

Will this mean I won't ever be allowed to install another release of
GCC without rebuilding glibc?  This is insane!

> In the end you might end up to have an individual configuration for
> each arch/OS/host/target combination.

This is the only reasonable approach.  Can you think for a second of
having the SONAMEs of libgcc.so managed by people other than the
maintainers of ports?  They're the ones who can tell when
backward-compatibility is broken for a certain platform.

> I don't know how to make this clearer, libgcc.so is a system library.

Is this just because glibc gets symbols from it?

AFAIK, the main problem is with changing exception-handling
interfaces.  Does glibc actually use these functions?  Couldn't we
just arrange for glibc to not be linked with the exception-handling
part of libgcc, since any program that uses them would be linked with
libgcc anyway?

Another option: couldn't libgcc's object files just be folded into
libc.so, without creating the hassle of yet another system library?

> Besides, I have not heard a single convincing argument why libgcc.so
> should be generate as part of gcc.  What do you want to achieve?

We want to solve the very same problem you're trying to solve, but not
with a we-only-care-about-GNU/Linux-issues point of view.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Tue, Jul 11, 2000 at 05:33:05PM -0300, Alexandre Oliva wrote:
> On Jul 11, 2000, Ulrich Drepper <drepper@redhat.com> wrote:
> 
> > Every application will be linked against this library and therefore it
> > must be available on the root filesystem where there is certainly no
> > room for gcc.
> 
> Will this mean I won't ever be allowed to install another release of
> GCC without rebuilding glibc?  This is insane!

No. That is why Ulrich suggested it be a standalone package.

> 
> > In the end you might end up to have an individual configuration for
> > each arch/OS/host/target combination.
> 
> This is the only reasonable approach.  Can you think for a second of
> having the SONAMEs of libgcc.so managed by people other than the
> maintainers of ports?  They're the ones who can tell when
> backward-compatibility is broken for a certain platform.

People who define the ABI don't necessarily to have to define the
SONAME or maintain the shared library. You can not just simply break
the backward-compatibility for libgcc.so since it will be a system
library. It has to be controlled by the system.

> 
> > I don't know how to make this clearer, libgcc.so is a system library.
> 
> Is this just because glibc gets symbols from it?

Yes.

> 
> AFAIK, the main problem is with changing exception-handling
> interfaces.  Does glibc actually use these functions?  Couldn't we

glibc wants to use it in the future.

> just arrange for glibc to not be linked with the exception-handling
> part of libgcc, since any program that uses them would be linked with
> libgcc anyway?

No.

> 
> Another option: couldn't libgcc's object files just be folded into
> libc.so, without creating the hassle of yet another system library?

That is what we do today and it doesn't work very well. If you don't
know why, ......

> 
> > Besides, I have not heard a single convincing argument why libgcc.so
> > should be generate as part of gcc.  What do you want to achieve?
> 
> We want to solve the very same problem you're trying to solve, but not
> with a we-only-care-about-GNU/Linux-issues point of view.
> 

As far as I know, only systems, where the shared C library uses gcc's
frame based exception, has this problem. Could you please name the
other systems?


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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Alexandre Oliva]

On Jul 11, 2000, Linus Torvalds <torvalds@transmeta.com> wrote:

> Ok. It sounds like that is a special routine, though. Mind if I ask why?

IIUC, the actual problem is that there are some static variable(s?) 
used to store frame data, so, if there are multiple copies of such
variables (which occurs when each shared library provides its own),
programs break.

> Might it not be better to consider that routine part of the crt0 kind of
> startup logic instead of a libgcc?

This might very well work, as long as it doesn't make it to shared
libraries.  However, it would require users of shared libraries
created with GCC to link with this crt file too.

The solution people have been proposing, of moving libgcc into a
separate shared library, would fix the problem for GNU/Linux, because
then each library wouldn't have its own copy of the EH-region-registry
functions nor of this variable.  However, it wouldn't solve the
problem on systems that don't store library dependencies in shared
libraries.  In such systems, shared libraries created with gcc would
have to be linked with libgcc in order to get the EH-region-registry
functions.  I'm pretty sure there are people out there that won't like
this, particularly people creating dlopen-able modules that are
intended to be dlopened by programs not linked with GCC.

Another idea that occurs to me: couldn't we just make this variable
non-static, so that dynamic loaders would resolve all references to it
into a single memory region?

Of course, this creates room for abuse of the interface (people might
feel tempted to use this variable directly), but we could document
this in the variable name, and give the users the choice of burning
themselves.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> Doing things outside gcc has the advantage of not delaying the
> release.  The worst case is that the new release cannot be used on a
> certain platform but that's it.  And this would be the fault of the
> people writing the libgcc.so for that arch/OS.

Maybe I'm missing another point here. I'm sure we can all argue
endlessly on that. However, this is GNU source, so you can take out
whatever you want from gcc and bundle it in whatever way you please.

You can then submit patches to gcc saying that certain things won't be
needed if some autoconf test determines they are already there. If you
think you (as the glibc group, or as the Ulrich Drepper individual)
can maintain this over the years to come - why don't you just go
ahead and do it?

> Besides, I have not heard a single convincing argument why libgcc.so
> should be generate as part of gcc.  What do you want to achieve?

It is likely that gcc maintainers will add functions to libgcc as they
please, and that the code generated by gcc will rely on these
functions being inside libgcc. So how should gcc proceed on a system
where these new functions are not present in the system libgcc?

Regards,
Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Tue, Jul 11, 2000 at 11:26:57PM +0200, Martin v. Loewis wrote:
> 
> > Besides, I have not heard a single convincing argument why libgcc.so
> > should be generate as part of gcc.  What do you want to achieve?
> 
> It is likely that gcc maintainers will add functions to libgcc as they
> please, and that the code generated by gcc will rely on these
> functions being inside libgcc. So how should gcc proceed on a system
> where these new functions are not present in the system libgcc?
> 

It has happened:

http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00018.html

That is why we discuss libgcc.so here. 

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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> Is there something really wrong with just sidestepping this issue
> altogether with the following simple rule:
> 
>  - libgcc is always statically linked inside the object file that needs
>    it (be it a binary or a shared library)
> 
> Yes. It will result in code duplication. Is that a huge problem?

The problem, in the past, was that there are also multiple copies of
static variables in the process. That was a huge problem, as some
function would put data into one variable, and another function would
expect it in another variable.

Regards,
Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Alexandre Oliva]

On Jul 11, 2000, "H . J . Lu" <hjl@valinux.com> wrote:

>> AFAIK, the main problem is with changing exception-handling
>> interfaces.  Does glibc actually use these functions?  Couldn't we

> glibc wants to use it in the future.

Ok

>> Another option: couldn't libgcc's object files just be folded into
>> libc.so, without creating the hassle of yet another system library?

> That is what we do today and it doesn't work very well. If you don't
> know why, ......

But, IIUC, the problem is that the symbols that must not be duplicated
are static, so dynamic loaders can't merge them together.  I *think*
if we made them global dynamic loaders arrange for all references to
them to point to the same symbol, and the problem would be solved.


Another possibility is that the EH-region data structures generated by
the compiler may change.  In this case, the functions that manage
registering and de-registering of EH regions might not understand the
data they're given.  The only way I see to solve this problem is to
rename the functions every time the data structures change, and
implement backward-compatibility replacement functions that convert
the data from the old format to the new one, then call the new
functions.

> As far as I know, only systems, where the shared C library uses
> gcc's frame based exception, has this problem.  Could you please
> name the other systems?

I doubt that's the case.  Any system that uses shared libraries should
be subject to the same problems, in case different modules are
compiled with incompatible versions of GCC.  But this probably occurs
more often on GNU/Linux precisely because libc isn't always compiled
by the compiler someone who installed their own version of GCC uses.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Geoff Keating]

> Date: Tue, 11 Jul 2000 12:48:32 -0700 (PDT)
> From: Linus Torvalds <torvalds@transmeta.com>
> cc: gcc@gcc.gnu.org
> 
> 
> 
> On Tue, 11 Jul 2000, Geoff Keating wrote:
> > > 
> > > Is there something really wrong with just sidestepping this issue
> > > altogether with the following simple rule:
> > > 
> > >  - libgcc is always statically linked inside the object file that needs
> > >    it (be it a binary or a shared library)
> > > 
> > > Yes. It will result in code duplication. Is that a huge problem?
> > 
> > Yes.  There is at least one routine in libgcc that must not be
> > duplicated; it relies on there being only one copy of itself in the
> > whole program.  This is the routine causing all the trouble.  We also
> > occasionally want to modify this routine, and you can't do that if
> > it's linked statically into every program.
> 
> Ok. It sounds like that is a special routine, though. Mind if I ask why?

This is the routine that keeps track of all the exception-handling
information.  Consider a program that uses the standard C function
qsort, but the comparison function can detect an I/O error (it's
sorting pointers to on-disk data) and throw an exception back to the
application.  The exception throwing mechanism has to know how to
unwind the comparison function's stack frame and the qsort stack
frames and then find the handler in the application which can
deal with the error; in general, it needs to know about every bit of
code loaded into the process.

> Might it not be better to consider that routine part of the crt0 kind of
> startup logic instead of a libgcc?

You mean, the crt1.o which is nine instructions long on powerpc, or
the startup logic which is ~1k lines in glibc?  We don't want the
first as it makes it impossible to upgrade as crt1 is linked into
every application, and the second is the current situation.

...
> Right now gcc cannot change the interfaces to the simple libgcc routines,
> because gcc doesn't control what libgcc things get linked against. Which
> means, for example, that optimizing things like "_cmpsdi2" to use a
> non-standard (and saner) calling convention etc is just not possible
> without strange and wonderful versioning schemes.

It's not that hard.  You simply call your new routine a new name.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Tue, Jul 11, 2000 at 06:53:07PM -0300, Alexandre Oliva wrote:
> 
> >> Another option: couldn't libgcc's object files just be folded into
> >> libc.so, without creating the hassle of yet another system library?
> 
> > That is what we do today and it doesn't work very well. If you don't
> > know why, ......
> 
> 
> Another possibility is that the EH-region data structures generated by
> the compiler may change.  In this case, the functions that manage
> registering and de-registering of EH regions might not understand the
> data they're given.  The only way I see to solve this problem is to

Right on.

> rename the functions every time the data structures change, and
> implement backward-compatibility replacement functions that convert
> the data from the old format to the new one, then call the new
> functions.

That is how it may be done in libgcc.so. But you cannot do it when
they are included in libc.so unless you rebuild libc.so. The idea
is we can easily rebuild libgcc.so without rebuilding libc.so.

> 
> > As far as I know, only systems, where the shared C library uses
> > gcc's frame based exception, has this problem.  Could you please
> > name the other systems?
> 
> I doubt that's the case.  Any system that uses shared libraries should
> be subject to the same problems, in case different modules are
> compiled with incompatible versions of GCC.  But this probably occurs

That is partially solved by my "library interface" scheme in gcc.
On any other system, you may change libstdc++ API and C++ ABI without
breaking the existing binaries. BTW, my scheme doesn't work with
libstdc++-v3 which uses libtool. It should be fixed.

> more often on GNU/Linux precisely because libc isn't always compiled
> by the compiler someone who installed their own version of GCC uses.
> 

The Linux C library is the only C library I know to use the frame based
exception in gcc.


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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:

> If you think you (as the glibc group, or as the Ulrich Drepper
> individual) can maintain this over the years to come - why don't you
> just go ahead and do it?

I've never said I want to do this.  I have enough to do.

> It is likely that gcc maintainers will add functions to libgcc as they
> please, and that the code generated by gcc will rely on these
> functions being inside libgcc. So how should gcc proceed on a system
> where these new functions are not present in the system libgcc?

The libgcc ABI cannot simply be changed without good reason and
preparation.  This should be clear meanwhile.  There must be much
finer coordination.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Henderson]

On Tue, Jul 11, 2000 at 10:34:05AM -0600, Jeffrey A Law wrote:
> Some native systems have multilibs.  alphas for example, maybe sparcs.
> And in the embedded linux world we will likely have systems that need
> multilibs.  We can't simply ignore those issues.

It'll take more than these two to convince me that we need multilibs on
natives.  Alpha can just as well use -mieee as the default build for
libgcc.so.  The sparc64 variants are used for sizing the memory model,
which is a non-issue if we put the thing in a DSO.


r~

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Henderson]

On Tue, Jul 11, 2000 at 10:40:28AM -0700, H . J . Lu wrote:
> > The fact that the Linux libc contains and reexports the frame info
> > registration functions make things a little more complicated, and
> 
> I believe it is the cause of the problem. Otherwise, it will be
> libstdc++.so who contains and reexports the frame info registration
> functions, which is the part of gcc and handled by my "library
> interface" scheme. It is an entirely different issuse.

Not at all.  It's exactly the same issue, with just the names changed.


r~

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Henderson]

On Tue, Jul 11, 2000 at 06:25:28PM -0300, Alexandre Oliva wrote:
> Another idea that occurs to me: couldn't we just make this variable
> non-static, so that dynamic loaders would resolve all references to it
> into a single memory region?

Not really.  If one has a blessed set of EH routines, one can
implement backward compatible interfaces with entry points that
frob the data before it's processed.  If one has global data,
and it appears there as if by magic, one cannot do this.


r~

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Linus Torvalds]

On Tue, 11 Jul 2000, Geoff Keating wrote:
> 
> This is the routine that keeps track of all the exception-handling
> information.  Consider a program that uses the standard C function
> qsort, but the comparison function can detect an I/O error (it's
> sorting pointers to on-disk data) and throw an exception back to the
> application.  The exception throwing mechanism has to know how to
> unwind the comparison function's stack frame and the qsort stack
> frames and then find the handler in the application which can
> deal with the error; in general, it needs to know about every bit of
> code loaded into the process.

And this is in libgcc?

What about dload() and friends? What about special loaders like the one
XFree86 uses to re-use different object files across different systems?
Sounds like a complete disaster to me.

Wouldn't it be better to _not_ consider this to be part of libgcc, and
instead have a well-defined EH record format and just tell people to use
it in their system libraries. Possibly with example code (ie the current
libgcc source for the problem at hand).

Because I don't think libgcc can handle the special cases anyway (see
above). And trying to is just going to cause problems.

		Linus

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Alexandre Oliva]

On Jul 11, 2000, "H . J . Lu" <hjl@valinux.com> wrote:

> That is how it may be done in libgcc.so. But you cannot do it when
> they are included in libc.so unless you rebuild libc.so. The idea
> is we can easily rebuild libgcc.so without rebuilding libc.so.

I see.

Are you aware that GCC is moving towards creating a shared libgcc?

Why, then, should glibc people take over the creation of this shared
library for GNU/Linux systems?  The GCC maintainers are going to have
to face this problem themselves, probably in a far more complicated
way since we don't care just about GNU/Linux.

Of course, we'll welcome contributions from the maintainers of glibc
with all GNU/Linux-specific knowledge about maintaining shared
libraries and keeping ABI compatibility, but I still feel the burden
of caring about maintaining ABI compatibility and managing library
version numbers can't be delegated to anybody else.  Of course, glibc
people can bug us any time we change an ABI, but glibc people won't be
able to fix any such ABI change except by hacking GCC or introducing
work-arounds that will be specific to GNU/Linux, and that therefore
won't affect users of other platforms GCC maintainers care about.

> On any other system, you may change libstdc++ API and C++ ABI without
> breaking the existing binaries.

What about rebuilding C++ shared libraries with an ABI-incompatible
GCC?  Do you claim this works on all platforms other than GNU/Linux?
I find it hard to believe.

>> more often on GNU/Linux precisely because libc isn't always compiled
>> by the compiler someone who installed their own version of GCC uses.

> The Linux C library is the only C library I know to use the frame based
> exception in gcc.

What I mean is that the problem occurs more often on GNU/Linux because
libc also carries the symbols GCC EH depends upon.  However, I believe
it should affect any other system when you link together shared
libraries created with ABI-incompatible versions of GCC.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Tue, Jul 11, 2000 at 07:22:52PM -0300, Alexandre Oliva wrote:
> I see.
> 
> Are you aware that GCC is moving towards creating a shared libgcc?
> 
> Why, then, should glibc people take over the creation of this shared
> library for GNU/Linux systems?  The GCC maintainers are going to have
> to face this problem themselves, probably in a far more complicated
> way since we don't care just about GNU/Linux.

The problem is we, Ulrich and I, don't believe gcc will do it right
for Linux in time. Very few people have the experiences of maintaining
a shared libary which is kept binary compatible with binaries compiled
years ago.

> > On any other system, you may change libstdc++ API and C++ ABI without
> > breaking the existing binaries.
> 
> What about rebuilding C++ shared libraries with an ABI-incompatible
> GCC?  Do you claim this works on all platforms other than GNU/Linux?

My scheme should work since it encodes the C library API, the libstdc++
API and the C++ compiler ABI in the soname of libstdc++.so.

> I find it hard to believe.

Try it.

> 
> >> more often on GNU/Linux precisely because libc isn't always compiled
> >> by the compiler someone who installed their own version of GCC uses.
> 
> > The Linux C library is the only C library I know to use the frame based
> > exception in gcc.
> 
> What I mean is that the problem occurs more often on GNU/Linux because
> libc also carries the symbols GCC EH depends upon.  However, I believe
> it should affect any other system when you link together shared
> libraries created with ABI-incompatible versions of GCC.
> 

It is only a problem for Linux because it happens to libc.so. If it
is something else, we can deal with it some other easy way.


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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Alexandre Oliva]

On Jul 11, 2000, "H . J . Lu" <hjl@valinux.com> wrote:

> The problem is we, Ulrich and I, don't believe gcc will do it right
> for Linux in time.

Please post your patches, even if they initially only work on
GNU/Linux.  Since we already have the encoding of ABI in the libstdc++
SONAME only on GNU/Linux, we can probably start by building libgcc.so
only on GNU/Linux too.


>> What about rebuilding C++ shared libraries with an ABI-incompatible
>> GCC?  Do you claim this works on all platforms other than GNU/Linux?

> My scheme should work since it encodes the C library API, the libstdc++
> API and the C++ compiler ABI in the soname of libstdc++.so.

It is my understanding that the encoding of the C library API is only
done on GNU/Linux.  I'm talking about other platforms.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jeffrey A Law]

  In message < 200007111736.e6BHabh26848@delius.kettenis.local >you write:
  > In essence, the issues aren't really a libgcc/libc issue.  Currently
  > all ELF systems have similar problems with getting exceptions working
  > in the presence of shared libraries.  Most of the other systems with
  > shared libraries probably suffer too.
  > 
  > The fact that the Linux libc contains and reexports the frame info
  > registration functions make things a little more complicated, and
  > might induce the need for some additional tweaks.  But the problem
  > isn't Linux-specific by far.
Precisely.   There's at least two (HP & DEC/Compaq) that have non-linux,
non-ELF systems which suffer from precisely the same core problems.

Jeff

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Tue, Jul 11, 2000 at 07:47:41PM -0300, Alexandre Oliva wrote:
> On Jul 11, 2000, "H . J . Lu" <hjl@valinux.com> wrote:
> 
> > The problem is we, Ulrich and I, don't believe gcc will do it right
> > for Linux in time.
> 
> Please post your patches, even if they initially only work on
> GNU/Linux.  Since we already have the encoding of ABI in the libstdc++
> SONAME only on GNU/Linux, we can probably start by building libgcc.so
> only on GNU/Linux too.
> 

I will do it as soon as I find some time.

> 
> >> What about rebuilding C++ shared libraries with an ABI-incompatible
> >> GCC?  Do you claim this works on all platforms other than GNU/Linux?
> 
> > My scheme should work since it encodes the C library API, the libstdc++
> > API and the C++ compiler ABI in the soname of libstdc++.so.
> 
> It is my understanding that the encoding of the C library API is only
> done on GNU/Linux.  I'm talking about other platforms.
> 

The maintainers of those platforms have to do it.


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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Date: Tue, 11 Jul 2000 15:12:24 -0700
   From: Richard Henderson <rth@cygnus.com>

   On Tue, Jul 11, 2000 at 10:40:28AM -0700, H . J . Lu wrote:
   > > The fact that the Linux libc contains and reexports the frame info
   > > registration functions make things a little more complicated, and
   > 
   > I believe it is the cause of the problem. Otherwise, it will be
   > libstdc++.so who contains and reexports the frame info registration
   > functions, which is the part of gcc and handled by my "library
   > interface" scheme. It is an entirely different issuse.

   Not at all.  It's exactly the same issue, with just the names changed.

Indeed.  Moreover, HJ's scheme doesn't even solve the problem of
rexporting the frame info registration info.  It may seem like it
does, but that's only because the C++ ABI changed more frequently than
the frame info registration.

The only thing HJ's scheme *does* "solve" is dealing with the libio
changes made between glibc 2.0 and glibc 2.1, that quite deliberately
ignored the consequences for C++ (since the C++ ABI was in flux anyway
at that time).  It's incredibly ugly, and I hope it can be phased out
in with Ggcc 3.0

   r~

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jeffrey A Law]

  In message < m31z10k1h6.fsf@otr.mynet.cygnus.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > > Yes, I'd forgotton about that.  It's one of the issues that needs to
  > > be addressed.  However, I'm not going to say "must never", just that it's
  > > an issues that must be resolved in one way or another.
  > 
  > Every application will be linked against this library and therefore it
  > must be available on the root filesystem where there is certainly no
  > room for gcc.
Not necessarily.  One could certainly argue that if it's on the root
filesystem that it ought to be linked statically.


  > > But we need to -- we're not just building a linux compiler.  We need this
  > > capability across a number of systems to resolve a number of nasty proble
  > ms.
  > 
  > We don't have to care about these things on other platforms (perhaps
  > on BSD but these people do their own stuff anyway).  The problem only
  > exists if the libc is using the code from libgcc and possibly
  > re-exports it.
Yes we do.  hpux, alpha-osf suffer from the same precise problems, only
the problem arises because of symbols that get sucked into libstdc++ and
reexported.

  > > Some native systems have multilibs.  alphas for example, maybe sparcs.
  > > And in the embedded linux world we will likely have systems that need
  > > multilibs.  We can't simply ignore those issues.
  > 
  > None of the systems we care about.
You may not, we do care.  Linux and glibc are just one of many systems we
have to care about in the GCC project.


  > We are completely missing each other.  You completely underestimate
  > the work needed to keep this compatibility library up-to-date.
How do you know that since I've stated nothing about how much effort
it will be to keep that library up to date.

  > Putting this in gcc means you cannot make a new release of gcc until
  > every single platform is handled (means, you have to actually review
  > all the interfaces for each OS/arch combination).
Yes.  And do you think you're telling me something new?

  > If nobody is
  > volunteering you have to do it yourself since otherwise you'll put out
  > a gcc version which can create incompatible binaries or breaks
  > existing one.  This is wrong.
The way to do it is with a binary compatibility testsuite.

  > Doing things outside gcc has the advantage of not delaying the
  > release.  The worst case is that the new release cannot be used on a
  > certain platform but that's it.  And this would be the fault of the
  > people writing the libgcc.so for that arch/OS.
Then do whatever you want *outside of gcc*, as it stands right now I'm
not going to support installing changes in gcc to do this until it's
better thought through.

  > It will also be up to the arch/OS groups to decide when binary
  > compatibility is dropped and all compatibility stuff from libgcc.so
  > should be dropped.
Actually, no.  After gcc-3.0 there aren't supposed to be binary incompatible
changes.  If there are, we will keep the old interfaces, potentially forever.

  > I don't know how to make this clearer, libgcc.so is a system library.
No, libgcc.so is a GCC library.

  > Unless you want to get into the system library development you should
  > not even consider handling the libgcc.so yourself.
I've done system library development and I can see the benefits of providing
these intrinsics in system libraries (and have even done so in a previous
life).  That doesn't mean I believe it's the best way to resolve this problem.

  > Besides, I have not heard a single convincing argument why libgcc.so
  > should be generate as part of gcc.  What do you want to achieve?
And I haven't heard a single convincing argument why it should not be
done in gcc.  What do you want to achive?

I have to think about multiple systems, I'm not going to put blinders on
and just fix linux/glibc problems.  That's not what the GCC project is
about.  

Part of my job is to make sure we do the right thing across the spectrum
of systems we have to support.  That means I have to take a more global
view than you or HJ does.



jeff

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[David Edelsohn]

>>>>> Richard Henderson writes:

> It'll take more than these two to convince me that we need multilibs on
> natives.  Alpha can just as well use -mieee as the default build for
> libgcc.so.  The sparc64 variants are used for sizing the memory model,
> which is a non-issue if we put the thing in a DSO.

	On AIX, multilibs select different architecture variants.  These
can make a lot of difference in the performance of the code generated for
DI helper functions based on longlong.h.  It is not clear that forcing
everyone to use the "common-mode" versions of the library for correct EH
behavior is acceptable.

David

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

Jeffrey A Law <law@cygnus.com> writes:

> Precisely.   There's at least two (HP & DEC/Compaq) that have non-linux,
> non-ELF systems which suffer from precisely the same core problems.

But they almost certainly need different solutions.

Anyway, this all is really becoming silly.  I've never said that I
wanted to write or maintain such a library.  I just don't believe that
the gcc people are able to maintain such a delicate interface for so
many platforms in a timely fashion given that you will also get
requests from the individual system library maintainers which have to
be taken into account.


You should stop making any incompatible changes before you can show a
solution for the problem.  Failing to do so, and the current situation
is already in the state, means that nobody can really use the current
compiler anymore since newly compiled binaries will crash.

I suggest to revert any such change and start working on the solution
of the interface problem.  Then we will see whether you can stand
behind your words.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jeffrey A Law]

  In message < m3d7kkgspg.fsf@otr.mynet.cygnus.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > > Precisely.   There's at least two (HP & DEC/Compaq) that have non-linux,
  > > non-ELF systems which suffer from precisely the same core problems.
  > 
  > But they almost certainly need different solutions.
The solution for both of those systems is a shared libgcc.so instead of
trying to make each library contain copies of all the libgcc routines
it uses.


  > Anyway, this all is really becoming silly.  I've never said that I
  > wanted to write or maintain such a library.  I just don't believe that
  > the gcc people are able to maintain such a delicate interface for so
  > many platforms in a timely fashion given that you will also get
  > requests from the individual system library maintainers which have to
  > be taken into account.
It's certainly not going to be easy, but it's what is going to have to be
done going forward.  There's simply no way around it looking at the kinds
of problems the GCC project is supposed to be solving in the not too
distant future.


  > You should stop making any incompatible changes before you can show a
  > solution for the problem.  Failing to do so, and the current situation
  > is already in the state, means that nobody can really use the current
  > compiler anymore since newly compiled binaries will crash.
I agree completely -- once we get gcc3.0 out the door.

  > I suggest to revert any such change and start working on the solution
  > of the interface problem.  Then we will see whether you can stand
  > behind your words.
So which ones are you referring to?
jeff

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Ulrich Drepper]

Jeffrey A Law <law@cygnus.com> writes:

> Not necessarily.  One could certainly argue that if it's on the root
> filesystem that it ought to be linked statically.

Jeff, don't be ridiculous.  First, you should look at the reality.
Second, you are not the one who decides about this.  This is what I
meant by taking input from the maintainers of all the different
systems you are targetting: they are setting the ground rules.

Now you can (hopefully) see what I meant when I said you completely
underestimate the work.  You'll have to please dozends of different
system implementors with your grand unified scheme.


I personally don't care a bit about all these issues.  I have no
problem with recompiling my whole system since I use almost no program
where this is not possible and for the few I cannot recompile I can
find a way around this problem.

But you can be sure you'll have a few million other people on your
rear end if you screw this up.  And not coming up with a solution soon
will certainly be in this category.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Date: Tue, 11 Jul 2000 15:02:16 -0700
   From: "H . J . Lu" <hjl@valinux.com>

   > more often on GNU/Linux precisely because libc isn't always compiled
   > by the compiler someone who installed their own version of GCC uses.
   > 

   The Linux C library is the only C library I know to use the frame based
   exception in gcc.

Ehm, it's the GNU C Library (glibc for short) and it's also use on the
Hurd (i386-unknown-gnu0.2) where we also include the same frame info.

(Sorry, I couldn't resist)

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Wed, Jul 12, 2000 at 01:07:47AM +0200, Mark Kettenis wrote:
>    > I believe it is the cause of the problem. Otherwise, it will be
>    > libstdc++.so who contains and reexports the frame info registration
>    > functions, which is the part of gcc and handled by my "library
>    > interface" scheme. It is an entirely different issuse.
> 
>    Not at all.  It's exactly the same issue, with just the names changed.
> 
> Indeed.  Moreover, HJ's scheme doesn't even solve the problem of
> rexporting the frame info registration info.  It may seem like it
> does, but that's only because the C++ ABI changed more frequently than
> the frame info registration.
> 
> The only thing HJ's scheme *does* "solve" is dealing with the libio
> changes made between glibc 2.0 and glibc 2.1, that quite deliberately
> ignored the consequences for C++ (since the C++ ABI was in flux anyway
> at that time).  It's incredibly ugly, and I hope it can be phased out
> in with Ggcc 3.0
> 

You really haven't seen my scheme in action. Check out the current
RedHat rawhide. They have 2 C++ compilers. egcs 1.1.2 is used to
compile KDE.

# ls  /usr/lib/libstdc++* 
/usr/lib/libstdc++-2-libc6.1-1-2.9.0.so   /usr/lib/libstdc++-libc6.2-2.a.3
/usr/lib/libstdc++-2-libc6.2-1-2.9.0.a    /usr/lib/libstdc++-libc6.2-2.so.3
/usr/lib/libstdc++-2-libc6.2-1-2.9.0.so   /usr/lib/libstdc++.so.2.7.2
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.a   /usr/lib/libstdc++.so.2.7.2.8
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so  /usr/lib/libstdc++.so.2.8
/usr/lib/libstdc++-libc6.1-1.so.2         /usr/lib/libstdc++.so.2.8.0
/usr/lib/libstdc++-libc6.2-1.a.2          /usr/lib/libstdc++.so.2.9
/usr/lib/libstdc++-libc6.2-1.so.2         /usr/lib/libstdc++.so.2.9.dummy
# rpm -qf /usr/lib/libstdc++-2-libc6.2-1-2.9.0.so
kernelcc-c++-1.1.2-4
# rpm -qf /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
libstdc++-2.96-33



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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Date: Tue, 11 Jul 2000 17:05:35 -0700
   From: "H . J . Lu" <hjl@valinux.com>

   You really haven't seen my scheme in action. Check out the current
   RedHat rawhide. They have 2 C++ compilers. egcs 1.1.2 is used to
   compile KDE.

   # ls  /usr/lib/libstdc++* 
   /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so   /usr/lib/libstdc++-libc6.2-2.a.3
   /usr/lib/libstdc++-2-libc6.2-1-2.9.0.a    /usr/lib/libstdc++-libc6.2-2.so.3
   /usr/lib/libstdc++-2-libc6.2-1-2.9.0.so   /usr/lib/libstdc++.so.2.7.2
   /usr/lib/libstdc++-3-libc6.2-2-2.10.0.a   /usr/lib/libstdc++.so.2.7.2.8
   /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so  /usr/lib/libstdc++.so.2.8
   /usr/lib/libstdc++-libc6.1-1.so.2         /usr/lib/libstdc++.so.2.8.0
   /usr/lib/libstdc++-libc6.2-1.a.2          /usr/lib/libstdc++.so.2.9
   /usr/lib/libstdc++-libc6.2-1.so.2         /usr/lib/libstdc++.so.2.9.dummy
   # rpm -qf /usr/lib/libstdc++-2-libc6.2-1-2.9.0.so
   kernelcc-c++-1.1.2-4
   # rpm -qf /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
   libstdc++-2.96-33

And you honestly believe this is a good thing?  It illustrates that
the libstdc++ are failing to properly version their library (which is
somewhat understandable since they've punted binary compatibility for
C++ until GCC 3.0).  And by giving them your "interface scheme" you've
provided them with the means to get away with it.  Just slap a
different soname on every permutation of things and you're not very
likely to get complaints about binary incompatibilities.

You see that you have both: libstdc++-2-libc6.1-1-2.9.0.so
and:                        libstdc++-2-libc6.2-1-2.9.0.so

I think those should be binary compatible (assuming this is a system
where glibc 2.2 is the installed system C library).

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Wed, Jul 12, 2000 at 01:37:21AM +0200, Mark Kettenis wrote:
>    Date: Tue, 11 Jul 2000 15:02:16 -0700
>    From: "H . J . Lu" <hjl@valinux.com>
> 
>    > more often on GNU/Linux precisely because libc isn't always compiled
>    > by the compiler someone who installed their own version of GCC uses.
>    > 
> 
>    The Linux C library is the only C library I know to use the frame based
>    exception in gcc.
> 
> Ehm, it's the GNU C Library (glibc for short) and it's also use on the
> Hurd (i386-unknown-gnu0.2) where we also include the same frame info.
> 

Ooops. Sorry for omission :-).


H.J.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Bill Nottingham]

Mark Kettenis (kettenis@wins.uva.nl) said: 
>    # rpm -qf /usr/lib/libstdc++-2-libc6.2-1-2.9.0.so
>    kernelcc-c++-1.1.2-4
>    # rpm -qf /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
>    libstdc++-2.96-33
> 
> And you honestly believe this is a good thing?

No, it was done as a stopgap to get working binaries for KDE while
we figured out what was wrong with the KDE source that it didn't
work right with the new compiler. That has been determined, and
the 'kernelcc-c++' thing is now very much dead.

(Not to comment on the whole shared libgcc thing, as I am
sure I don't understand all the issues involved...)

Bill

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Wed, Jul 12, 2000 at 02:55:12AM +0200, Mark Kettenis wrote:
>    Date: Tue, 11 Jul 2000 17:05:35 -0700
>    From: "H . J . Lu" <hjl@valinux.com>
> 
>    You really haven't seen my scheme in action. Check out the current
>    RedHat rawhide. They have 2 C++ compilers. egcs 1.1.2 is used to
>    compile KDE.
> 
>    # ls  /usr/lib/libstdc++* 
>    /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so   /usr/lib/libstdc++-libc6.2-2.a.3
>    /usr/lib/libstdc++-2-libc6.2-1-2.9.0.a    /usr/lib/libstdc++-libc6.2-2.so.3
>    /usr/lib/libstdc++-2-libc6.2-1-2.9.0.so   /usr/lib/libstdc++.so.2.7.2
>    /usr/lib/libstdc++-3-libc6.2-2-2.10.0.a   /usr/lib/libstdc++.so.2.7.2.8
>    /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so  /usr/lib/libstdc++.so.2.8
>    /usr/lib/libstdc++-libc6.1-1.so.2         /usr/lib/libstdc++.so.2.8.0
>    /usr/lib/libstdc++-libc6.2-1.a.2          /usr/lib/libstdc++.so.2.9
>    /usr/lib/libstdc++-libc6.2-1.so.2         /usr/lib/libstdc++.so.2.9.dummy
>    # rpm -qf /usr/lib/libstdc++-2-libc6.2-1-2.9.0.so
>    kernelcc-c++-1.1.2-4
>    # rpm -qf /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
>    libstdc++-2.96-33
> 
> And you honestly believe this is a good thing?  It illustrates that

I believe it is a working solution. It is far from perfect. But it
is better than nothing. If you don't like mine, I'd like to hear
yours. It'd better be working TODAY.

> the libstdc++ are failing to properly version their library (which is
> somewhat understandable since they've punted binary compatibility for
> C++ until GCC 3.0).  And by giving them your "interface scheme" you've

Do you think why they can punt binary compatibility? Why haven't Linux
users complained very loudly?

> provided them with the means to get away with it.  Just slap a
> different soname on every permutation of things and you're not very
> likely to get complaints about binary incompatibilities.

Do you have any suggestions? Don't tell me GCC 3.0 will solve
everything. Red Hat already uses gcc 2.96 in rawhide. One of the
reasons I believe is gcc 2.95 and egcs 1.1.2 won't compile glibc 2.2.
I hope they won't use gcc 2.96 in the public release.

> 
> You see that you have both: libstdc++-2-libc6.1-1-2.9.0.so
> and:                        libstdc++-2-libc6.2-1-2.9.0.so
> 
> I think those should be binary compatible (assuming this is a system
> where glibc 2.2 is the installed system C library).

I don't know for sure. I believe they aren't C++ binary compatible.


H.J.

A sample implemenation (Re: My proposal for the libgcc runtime ABI)

[H . J . Lu]

On Tue, Jul 11, 2000 at 07:47:41PM -0300, Alexandre Oliva wrote:
> On Jul 11, 2000, "H . J . Lu" <hjl@valinux.com> wrote:
> 
> > The problem is we, Ulrich and I, don't believe gcc will do it right
> > for Linux in time.
> 
> Please post your patches, even if they initially only work on
> GNU/Linux.  Since we already have the encoding of ABI in the libstdc++
> SONAME only on GNU/Linux, we can probably start by building libgcc.so
> only on GNU/Linux too.
> 

This is not a real patch. It just shows how it can done under Linux.
You will need

http://gcc.gnu.org/ml/gcc-bugs/2000-07/msg00117.html

for <runtime.h>. When it is used with glibc build, we can use

..../libgcc/libgcc.so `$(CC) -print-libgcc-file-name`

or

..../libgcc/libgcc.so -lgcc

instead of just -lgcc.


H.J.
----
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.2.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 2000-07-11 21:42 PDT by <hjl@osmium.su.varesearch.com>.
# Source directory was `/work/gnu/src/libgcc'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#   1081 -rw-r--r-- Makefile
#    297 -rw-r--r-- dummy.c
#
save_IFS="${IFS}"
IFS="${IFS}:"
gettext_dir=FAILED
locale_dir=FAILED
first_param="$1"
for dir in $PATH
do
  if test "$gettext_dir" = FAILED && test -f $dir/gettext \
     && ($dir/gettext --version >/dev/null 2>&1)
  then
    set `$dir/gettext --version 2>&1`
    if test "$3" = GNU
    then
      gettext_dir=$dir
    fi
  fi
  if test "$locale_dir" = FAILED && test -f $dir/shar \
     && ($dir/shar --print-text-domain-dir >/dev/null 2>&1)
  then
    locale_dir=`$dir/shar --print-text-domain-dir`
  fi
done
IFS="$save_IFS"
if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED
then
  echo=echo
else
  TEXTDOMAINDIR=$locale_dir
  export TEXTDOMAINDIR
  TEXTDOMAIN=sharutils
  export TEXTDOMAIN
  echo="$gettext_dir/gettext -s"
fi
if touch -am -t 200112312359.59 $$.touch >/dev/null 2>&1 && test ! -f 200112312359.59 -a -f $$.touch; then
  shar_touch='touch -am -t $1$2$3$4$5$6.$7 "$8"'
elif touch -am 123123592001.59 $$.touch >/dev/null 2>&1 && test ! -f 123123592001.59 -a ! -f 123123592001.5 -a -f $$.touch; then
  shar_touch='touch -am $3$4$5$6$1$2.$7 "$8"'
elif touch -am 1231235901 $$.touch >/dev/null 2>&1 && test ! -f 1231235901 -a -f $$.touch; then
  shar_touch='touch -am $3$4$5$6$2 "$8"'
else
  shar_touch=:
  echo
  $echo 'WARNING: not restoring timestamps.  Consider getting and'
  $echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 200112312359.59 123123592001.59 123123592001.5 1231235901 $$.touch
#
if mkdir _sh17043; then
  $echo 'x -' 'creating lock directory'
else
  $echo 'failed to create lock directory'
  exit 1
fi
# ============= Makefile ==============
if test -f 'Makefile' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'Makefile' '(file already exists)'
else
  $echo 'x -' extracting 'Makefile' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'Makefile' &&
LD=ld
CC=/opt/gcc-3.0/bin/gcc
X
LN_S=ln -s
X
INSTALL_PROGRAM=install -c
X
slibdir=/lib
X
inst_slibdir=$(install_root)$(slibdir)
X
libgcc-a=$(shell $(CC) -print-libgcc-file-name)
libgcc-so=$(shell $(CC) -print-libgcc-file-name | sed -e 's/a$$/so/')
X
soname=libgcc.so.3
libgcc=libgcc-$(shell $(CC) -dumpversion).so
X
libgcc.so: dummy.o $(libgcc-a)
X	$(LD) -shared -soname $(soname) -o $@ $^
X
dummy.o: dummy.c
X	$(CC) -fPIC -O -c $<
X
install: $(install_root)$(libgcc-so) $(inst_slibdir)/$(soname)
X
$(inst_slibdir)/$(libgcc): $(libgcc)
X	mkdir -p $(@D)
X	rm -f $@.new 
X	$(INSTALL_PROGRAM) $< $@.new
X	mv $@.new $@
X
$(inst_slibdir)/$(soname): $(inst_slibdir)/$(libgcc)
X	mkdir -p $(@D)
X	rm -f $@.new 
X	$(LN_S) $< $@.new
X	mv $@.new $@
X
$(install_root)$(libgcc-so): libgcc.so $(libgcc-a)
X	mkdir -p $(@D)
X	(echo '/* GNU ld script';\
X	 echo '   Use the shared library, but some functions are only in';\
X	 echo '   the static library, so try that secondarily.  */';\
X	 echo 'GROUP ( $(slibdir)/$(soname)' \
X	      '$(libgcc-a))' \
X	) > $@.new
X	mv -f $@.new $@
X
clean:
X	rm -f dummy.o $(soname) libgcc.so
SHAR_EOF
  (set 20 00 07 11 21 39 24 'Makefile'; eval "$shar_touch") &&
  chmod 0644 'Makefile' ||
  $echo 'restore of' 'Makefile' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'Makefile:' 'MD5 check failed'
7da3126882752574533e8b1919cdc416  Makefile
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'Makefile'`"
    test 1081 -eq "$shar_count" ||
    $echo 'Makefile:' 'original size' '1081,' 'current size' "$shar_count!"
  fi
fi
# ============= dummy.c ==============
if test -f 'dummy.c' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'dummy.c' '(file already exists)'
else
  $echo 'x -' extracting 'dummy.c' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'dummy.c' &&
#include <runtime.h>
X
static
const void *dummy [] =
{
X  (const void *) __register_frame,
X  (const void *) __register_frame_table,
X  (const void *) __deregister_frame,
X  (const void *) __register_frame_info,
X  (const void *) __register_frame_info_table,
X  (const void *) __deregister_frame_info
};
SHAR_EOF
  (set 20 00 07 11 21 01 25 'dummy.c'; eval "$shar_touch") &&
  chmod 0644 'dummy.c' ||
  $echo 'restore of' 'dummy.c' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'dummy.c:' 'MD5 check failed'
a6d5eb1b19ef9afbc7a2b96e151ef6ae  dummy.c
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'dummy.c'`"
    test 297 -eq "$shar_count" ||
    $echo 'dummy.c:' 'original size' '297,' 'current size' "$shar_count!"
  fi
fi
rm -fr _sh17043
exit 0

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> > If you think you (as the glibc group, or as the Ulrich Drepper
> > individual) can maintain this over the years to come - why don't you
> > just go ahead and do it?
> 
> I've never said I want to do this.  I have enough to do.

Are we having a theoretical discussion, then? Who is volunteering the
maintain this package over the years to come?

Regards,
Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> The libgcc ABI cannot simply be changed without good reason and
> preparation.  This should be clear meanwhile.  There must be much
> finer coordination.

But given good reason and preparation, how could gcc then make use of
the added features, if libgcc.so is a third-party product?

Regards,
Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Geoff Keating]

> Date: Tue, 11 Jul 2000 15:22:34 -0700 (PDT)
> From: Linus Torvalds <torvalds@transmeta.com>
> cc: gcc@gcc.gnu.org
> 
> 
> 
> On Tue, 11 Jul 2000, Geoff Keating wrote:
> > 
> > This is the routine that keeps track of all the exception-handling
> > information.  Consider a program that uses the standard C function
> > qsort, but the comparison function can detect an I/O error (it's
> > sorting pointers to on-disk data) and throw an exception back to the
> > application.  The exception throwing mechanism has to know how to
> > unwind the comparison function's stack frame and the qsort stack
> > frames and then find the handler in the application which can
> > deal with the error; in general, it needs to know about every bit of
> > code loaded into the process.
> 
> And this is in libgcc?

Yes.  It's support code for gcc.

> What about dload() and friends?

They (are supposed to) work.  The registration routines are called
from the dynamic object's initialisation routine.  This is not a
radical new design, many other systems use it.

> What about special loaders like the one XFree86 uses to re-use
> different object files across different systems?

If they want to make EH work, they have to run initialisation routines
too.  That's usually the least of their problems.  Usually people
doing such things deal with this issue by simply prohibiting exception
throwing inside or across such object files---I doubt the XFree86
people find this a problem.

> Sounds like a complete disaster to me.

It has worked well so far.

> Wouldn't it be better to _not_ consider this to be part of libgcc, and
> instead have a well-defined EH record format and just tell people to use
> it in their system libraries. Possibly with example code (ie the current
> libgcc source for the problem at hand).

There are already well-defined EH record formats for AIX, Solaris,
ia64, and Linux, and probably others.  It's just a shame that they're
all different, and gcc doesn't have the resources to support all of
them, and some of them don't work for gcc anyway because they were
designed without sufficient generality.

> Because I don't think libgcc can handle the special cases anyway (see
> above). And trying to is just going to cause problems.

It's one thing to try to handle every weird combination of user-loaded
code, shared libraries dlopened into static applications, and so on.
It's quite another to expect that in the usual case, of shared
libraries, dlopen()ed plug-ins, and normal C and C++ code, that
everything should work automatically.  This usual case already works,
it's just that we want more freedom than our current implementation
allows.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Wed, Jul 12, 2000 at 08:00:05AM +0200, Martin v. Loewis wrote:
> > The libgcc ABI cannot simply be changed without good reason and
> > preparation.  This should be clear meanwhile.  There must be much
> > finer coordination.
> 
> But given good reason and preparation, how could gcc then make use of
> the added features, if libgcc.so is a third-party product?

gcc has to well document the added ABI functions. It will be added
to the target specific libgcc.so package after testing which is
specific to each individual target. Some may choose to drop backward
compatibilty and some may want to keep it. Some may come back to gcc
and say that the changes are not acceptable unless such such
modifications are made. It is very tricky stuff specific to each
individual target system software. I don't believe gcc has the sources
to do it right on all targets. IMHO, delegating it to each target is
the only sane way to go.


H.J.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Wed, Jul 12, 2000 at 08:01:14AM +0200, Martin v. Loewis wrote:
> > > If you think you (as the glibc group, or as the Ulrich Drepper
> > > individual) can maintain this over the years to come - why don't you
> > > just go ahead and do it?
> > 
> > I've never said I want to do this.  I have enough to do.
> 
> Are we having a theoretical discussion, then? Who is volunteering the
> maintain this package over the years to come?
> 

Can you tell me who are going to maintain Linux for years to come?
We, VA Linux, have sold so many Linux machines. What do we do? The
answer is you don't have to worry about it. Someone will maintain it,
one way or the other, just like gcc, kernel, X11, glibc, binutils,
...... libgcc.so is no different.



H.J.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Joe Buck]

> Do you have any suggestions? Don't tell me GCC 3.0 will solve
> everything. Red Hat already uses gcc 2.96 in rawhide. One of the
> reasons I believe is gcc 2.95 and egcs 1.1.2 won't compile glibc 2.2.
> I hope they won't use gcc 2.96 in the public release.

There is no 2.96, and 3.0 won't be released until problems like this are
fixed.

The goal of 3.0 is to freeze the C++ ABI so we don't keep going through
these problems again and again.  That means we have to get it right.
Thanks in advance for contributing to the effort to get it right.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> Can you tell me who are going to maintain Linux for years to come?
> We, VA Linux, have sold so many Linux machines. What do we do? The
> answer is you don't have to worry about it. Someone will maintain it,
> one way or the other, just like gcc, kernel, X11, glibc, binutils,
> ...... libgcc.so is no different.

That's not a convincing response. For each of the packages you cited,
there is some person or organization supporting it, in the sense of
ongoing development (gcc steering committee, Linus Torvalds, XFree
Consortium, Ulrich Drepper, Cygnus/Redhat). Those I trust that they
will be there five years from now, or hand it over before they go
away.

Something being "Linux" is not a guarantee for ongoing support; many
projects have been abandoned, or stagnate forever (my NTFS driver is
an example; another is the bpe editor).

Are you saing VA Linux would commit to maintain libgcc.so? That would
be convincing also.

Regards,
Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Wed, Jul 12, 2000 at 07:44:02PM +0200, Martin v. Loewis wrote:
> > Can you tell me who are going to maintain Linux for years to come?
> > We, VA Linux, have sold so many Linux machines. What do we do? The
> > answer is you don't have to worry about it. Someone will maintain it,
> > one way or the other, just like gcc, kernel, X11, glibc, binutils,
> > ...... libgcc.so is no different.
> 
> That's not a convincing response. For each of the packages you cited,
> there is some person or organization supporting it, in the sense of
> ongoing development (gcc steering committee, Linus Torvalds, XFree
> Consortium, Ulrich Drepper, Cygnus/Redhat). Those I trust that they
> will be there five years from now, or hand it over before they go
> away.
> 
> Something being "Linux" is not a guarantee for ongoing support; many
> projects have been abandoned, or stagnate forever (my NTFS driver is
> an example; another is the bpe editor).
> 
> Are you saing VA Linux would commit to maintain libgcc.so? That would
> be convincing also.
> 

I don't speak for VA Linux. But I can ensure you that VA Linux has a vast
interest in an actively maintained Linux system. A working libgcc.so
belongs to that category. I will bet Red Hat, SuSE, ..... and many other
Linux system software vendors will be very interested in it also.

BTW, I guess Ulrich Drepper wants a reasonable libgcc.so solution for glibc
too.


H.J.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> Wouldn't it be better to _not_ consider this to be part of libgcc, and
> instead have a well-defined EH record format and just tell people to use
> it in their system libraries.

There is a well-defined format. The problem is that you need a
process-wide list of such structures, to find the entry points into
the structures when an exception is thrown in one library and caught
in another.

Regards,
Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Linus Torvalds]

On Wed, 12 Jul 2000, Martin v. Loewis wrote:
>
> > Wouldn't it be better to _not_ consider this to be part of libgcc, and
> > instead have a well-defined EH record format and just tell people to use
> > it in their system libraries.
> 
> There is a well-defined format. The problem is that you need a
> process-wide list of such structures, to find the entry points into
> the structures when an exception is thrown in one library and caught
> in another.

But what has this got to do with gcc?

Nothing. It's a systems issue. Gcc just needs to honor the format, the
same way gcc needs to generate a lot of other "helper" information (which
is, of course, mainly for debugging, but things like global namescape
information is a similar thing where gcc emits certain records to tell the
assembler which symbols are global etc).

If the format is well-defined, then you should consider this to be a
loader and systems thing, not a gcc thing. Why are the routines in libgcc
at all? Why aren't they in the loaders, or the libraries?

I think it was Kenner who said that libgcc should only contain code that
is actually called by gcc-generated code. That's a good definition of what
libgcc used to be. Why not go back to that, and leave the whole EH thing
into the hands of the glibc and other people working on libraries and
systems issues.

(And yes, I know there are non-glibc systems out there. Obviously. But
those systems still need to be aware of EH stuff if exceptions are to be
used at all. So the same arguments apply there - glibc is _not_ special,
and should not be considered special).

			Linus

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> But what has this got to do with gcc?
[...]
> I think it was Kenner who said that libgcc should only contain code that
> is actually called by gcc-generated code.

The EH functions *are* invoked by gcc, in particular by cc1plus. It
emits calls to functions which unwind the stack and thus need to get
at the global list of unwind tables.

> And yes, I know there are non-glibc systems out there. Obviously. But
> those systems still need to be aware of EH stuff if exceptions are to be
> used at all.

As a matter of fact, g++ works on those systems without any
cooperation from those systems. It does so by providing specific crt
files, crtbegin and crtend, which deal with the management of the EH
unwind tables.

Regards,
Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Henderson]

On Wed, Jul 12, 2000 at 01:30:47PM -0700, Linus Torvalds wrote:
> If the format is well-defined, then you should consider this to be a
> loader and systems thing, not a gcc thing. Why are the routines in libgcc
> at all? Why aren't they in the loaders, or the libraries?

This is just passing the buck, and does no one any good.

Look: it's not a loader thing, because the loader is and has been doing
exactly what it was designed to do.  Namely, map binaries in memory and
resolve symbols.

It is a library thing, but there's no standard library to defer to.  What
library do we have control of under Solaris except libgcc?  Quite a lot
of the system vendors have their own special hacky way to do exception
handling, and most of them suck.  We're using dwarf2 (almost) across the
board, and that, with the exception of Irix, means we'd have to write our
own code to handle the unwinding, etc.

Further, even under Linux we don't want to pawn this off even on glibc. 
(Ignoring the fact that I don't think Linux should be an exception for the
GCC team managing the EH routines.)  The scenario is that someone's got
last year's glibc installed, which has all the EH routines they need. 
Along comes P3 and SSE which requires us to enforce stack alignment,
which requires masking the incoming stack pointer and other such ugliness,
which requires emitting new sorts of unwind directives that the old EH
routines were never designed to handle.  Which means that our hapless user
has to wait for and upgrade to the next glibc release in order to use this
new gcc feature.  As opposed to having gcc provide an update to the shared
library that handles exception handling.

> I think it was Kenner who said that libgcc should only contain code that
> is actually called by gcc-generated code. That's a good definition of what
> libgcc used to be.

And still is.  GCC does generate calls to the EH routines.  We generate
calls to the EH registration routines at startup, and we generate calls
to the EH dispatch routines at runtime.

How else do you think `throw new int(8);' happens?

There's no point in this thread going further.  There is exactly zero
chance that the GCC team will not manage GCC exception handling routines.
It will not be spun off to a self-contained package, and Linux will not
be special cased wrt deferring to "system libraries", i.e. glibc.


r~

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Linus Torvalds]

On Wed, 12 Jul 2000, Martin v. Loewis wrote:
> 
> > And yes, I know there are non-glibc systems out there. Obviously. But
> > those systems still need to be aware of EH stuff if exceptions are to be
> > used at all.
> 
> As a matter of fact, g++ works on those systems without any
> cooperation from those systems. It does so by providing specific crt
> files, crtbegin and crtend, which deal with the management of the EH
> unwind tables.

I guess my basic message is: shouldn't this all be split up from the
"core" gcc setup? 

The people who do crt files etc are usually not the same people who do
good compilers. And potentially holding up gcc releases because of issues
like where you put the EH functionality on Linux/Solaris/WNT/whatever
sounds like wasteful.

Wouldn't it be nicer to just do a gcc release and let the people like hjl
sort out the crt files. As they've said, they end up having to do that
_anyway_, so doing it inside gcc is to some degree just a waste of time..

		Linus

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Michael Meissner]

On Wed, Jul 12, 2000 at 01:30:47PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 12 Jul 2000, Martin v. Loewis wrote:
> >
> > > Wouldn't it be better to _not_ consider this to be part of libgcc, and
> > > instead have a well-defined EH record format and just tell people to use
> > > it in their system libraries.
> > 
> > There is a well-defined format. The problem is that you need a
> > process-wide list of such structures, to find the entry points into
> > the structures when an exception is thrown in one library and caught
> > in another.
> 
> But what has this got to do with gcc?
> 
> Nothing. It's a systems issue. Gcc just needs to honor the format, the
> same way gcc needs to generate a lot of other "helper" information (which
> is, of course, mainly for debugging, but things like global namescape
> information is a similar thing where gcc emits certain records to tell the
> assembler which symbols are global etc).
> 
> If the format is well-defined, then you should consider this to be a
> loader and systems thing, not a gcc thing. Why are the routines in libgcc
> at all? Why aren't they in the loaders, or the libraries?
> 
> I think it was Kenner who said that libgcc should only contain code that
> is actually called by gcc-generated code. That's a good definition of what
> libgcc used to be. Why not go back to that, and leave the whole EH thing
> into the hands of the glibc and other people working on libraries and
> systems issues.

This makes sense to me.  Note, however GCC does call the EH functions, and it
needs to know how to lay out the tables, so there are definite ABI issues
involved.  Note, you can't use include file magic if glibc ever wanted to
change the format, since the compiler will be generating the information as
part of code generation.  GCC does have to provide the complete EH setup for
systems that don't provide EH (including glibc 2.1), and will continue to have
to provide it, which means the core of EH functions will be implemented twice,
once in GCC to support systems whose libraries don't support EH (including
embedded processors), and once in glibc.  I would say, that whatever new
version of __register_frame_info include a version # so that we don't have the
same problem come bite us 2 years hence.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Martin v. Loewis]

> Wouldn't it be nicer to just do a gcc release and let the people like hjl
> sort out the crt files. As they've said, they end up having to do that
> _anyway_, so doing it inside gcc is to some degree just a waste of time..

The people like hjl could do that right now. For WNT, there are people
doing that (packaging precompiled gcc together with precompiled
libraries). However, they contribute their work back to gcc because
that makes their lifes simpler. For Linux, nobody stepped forward so
far. For Solaris and the others, I believe it is impossible to find
volunteers with the necessary expertise, except for the regular gcc
contributors.

Regards,
Martin

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Geoff Keating]

> Date: Wed, 12 Jul 2000 14:12:14 -0700 (PDT)
> From: Linus Torvalds <torvalds@transmeta.com>

> Wouldn't it be nicer to just do a gcc release and let the people like hjl
> sort out the crt files. As they've said, they end up having to do that
> _anyway_, so doing it inside gcc is to some degree just a waste of time..

There's no point making a gcc release that does not work on linux.
These issues have to be sorted out before the release.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Zack Weinberg]

On Tue, Jul 11, 2000 at 12:41:40AM -0700, Richard Henderson wrote:
> On Mon, Jul 10, 2000 at 06:10:55PM -0700, Zack Weinberg wrote:
> > I ask again, why do we need libtool?  What supported platform cannot
> > be handled by teaching the Makefile the magic switches to pass to the
> > compiler and linker?
> 
> We don't, necessarily.  But make in general doesn't have complex
> macro expansion.  Which implies we'll have to have some sort of
> script-y thing.  Either that or leave the entire library target
> in the target makefile fragment.

I don't see the need for complex macro expansion, either.  You write

SO_OBJS = a.os b.os c.os d.os

libfoo$(soext): $(SO_OBJS)
	$(CC) $(CFLAGS) $(SHLIB_LDFLAGS) $(SO_OBJS) -o $@
	$(MAYBE_POSTPROCESS_SHLIB) $@

.SUFFIXES: .os
.c.os:
	$(CC) $(CFLAGS) $(CPPFLAGS) $(PIC_CFLAGS) $< -o $@

and have soext, PIC_CFLAGS, MAYBE_POSTPROCESS_SHLIB, and SHLIB_LDFLAGS
set by either configure or the target fragments.  And that is enough
for every shared library system I've ever seen except Linux/a.out,
which we don't care about anyway.

I might also point out that this is libgcc we're talking about.  Which
means we know that CC is gcc, and we already have the mklibgcc script
should we need to do anything contorted.

[We do have to worry about libgcc1.c - I'd be in favor of eliminating
it for GCC 3.0.  And the .asm files some systems put in libgcc will
have to be ifdefed up for PIC, but that's not hard.]

zw

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Alexandre Oliva]

On Jul 11, 2000, Alexandre Oliva <aoliva@redhat.com> wrote:

> Why, then, should glibc people take over the creation of this shared
> library for GNU/Linux systems?

Now here's one additional, interesting problem.  Assume libgcc is a
shared library.  It has obviously been linked with some version of
libc, given that it uses symbols from libc.  This means it will have a
dependency on some particular libc SONAME encoded in it.

Now think of glibc: since it uses libgcc, it will also have some
particular libgcc SONAME encoded in it.  But libgcc already depended
on libc, so we have a circularity.  No big deal: each library will
only be loaded once, and everything is fine, right?  Despite the minor
problem of how to bootstrap this situation.

But there's a major problem too.  What if I decide to upgrade one of
GCC or glibc.  What now?  New programs I create will depend on the
most recent libgcc and glibc, but one of the libraries (the one that
was not updated) will depend on the older version of the other.  So,
if I had upgraded GCC, I'd have two different, potentially
incompatible versions, of libgcc loaded into the same process.  I'm
afraid this may not work.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jason R Thorpe]

On Thu, Jul 13, 2000 at 06:35:37PM -0300, Alexandre Oliva wrote:

 > But there's a major problem too.  What if I decide to upgrade one of
 > GCC or glibc.  What now?  New programs I create will depend on the
 > most recent libgcc and glibc, but one of the libraries (the one that
 > was not updated) will depend on the older version of the other.  So,
 > if I had upgraded GCC, I'd have two different, potentially
 > incompatible versions, of libgcc loaded into the same process.  I'm
 > afraid this may not work.

This seems like a classic example of:

Patient: "It hurts when I do this."
Doctor: "Well, then don't do that."

I.e. the obvious solution is to not install libgcc as a shared
library.  I know this is how the BSDs do things, and it seems to
work well through both libc and compiler upgrades.

You could also use symbol renaming to keep backwards-compatible
versions of the functions in the new library.  This is what NetBSD
does to avoid having to bump its libc major number[*] when various
bits of the libc/syscall ABI change for one reason or another.

For example, when NetBSD changed the layout of the `stat' structure:

#ifdef __LIBC12_SOURCE__
int     stat __P((const char *, struct stat12 *));
int     fstat __P((int, struct stat12 *));
int     __stat13 __P((const char *, struct stat *));
int     __fstat13 __P((int, struct stat *));
#else
int     stat __P((const char *, struct stat *)) __RENAME(__stat13);  
int     fstat __P((int, struct stat *))         __RENAME(__fstat13);
#endif

...where `12' and `13' refer to the major versions of those functions.
In the event that the libc major is bumped to 13 some day, the old
functions go away, and the renamed functions get moved into their
rightful place in the namespace.

FWIW, those __RENAME() examples above expand into:

	__asm__("__stat13")
	__asm__("__fstat13")

As long as the prototypes are in-scope, you get the correct versions
of the functions.  In the event that the prototypes are not in-scope
(e.g. some lazy 3rd party package), there are linker stubs that produce
warnings when the program is linked indicating that the incorrect
versions of the functions were used, and that the program should be
modified to bring prototypes into scope.

[*] Bumping libc major is a serious pain.  When you do, you basically
need to bump the major number of all other shared libraries, as well,
since they use libc symbols.  This is not unlike the problem with
shared libgcc/libc you are talking about.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Earnshaw]

thorpej@zembu.com said:
> I.e. the obvious solution is to not install libgcc as a shared
> library.  I know this is how the BSDs do things, and it seems to work
> well through both libc and compiler upgrades. 

This isn't quite true.  We don't install a shared libgcc on BSD platforms 
because libc has replacements for the most common libgcc functions built 
into it.  This is an equally disgusting hack because it assumes that the 
definitions in there will be sufficient even if the compiler is upgraded.  
I suspect it will cause even more problems moving forward when we need to 
include exception management support.

Richard.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   From: Alexandre Oliva <aoliva@redhat.com>
   Date: 13 Jul 2000 18:35:37 -0300

   On Jul 11, 2000, Alexandre Oliva <aoliva@redhat.com> wrote:

   > Why, then, should glibc people take over the creation of this shared
   > library for GNU/Linux systems?

   Now here's one additional, interesting problem.  Assume libgcc is a
   shared library.  It has obviously been linked with some version of
   libc, given that it uses symbols from libc.  This means it will have a
   dependency on some particular libc SONAME encoded in it.

That isn't necessary per se.  You can have undefined references in a
shared library.

   Now think of glibc: since it uses libgcc, it will also have some
   particular libgcc SONAME encoded in it.  But libgcc already depended
   on libc, so we have a circularity.  No big deal: each library will
   only be loaded once, and everything is fine, right?  Despite the minor
   problem of how to bootstrap this situation.

The bootstrapping problem is solvable with DT_AUXILIARY.  If libc
contains a DT_AUXILIARY entry for libgcc, instead of an ordinary
dependency (DT_NEEDED), libc will only use libgcc if it does exist.
This means that libc itself would still have to contain copies of the
stuff from libgcc that it explicitly exports now, but these could
become dummy versions in the long run.

   But there's a major problem too.  What if I decide to upgrade one of
   GCC or glibc.  What now?  New programs I create will depend on the
   most recent libgcc and glibc, but one of the libraries (the one that
   was not updated) will depend on the older version of the other.  So,
   if I had upgraded GCC, I'd have two different, potentially
   incompatible versions, of libgcc loaded into the same process.  I'm
   afraid this may not work.

That's why the initial message on the gcc lists where the GCC
devlopers announced their intention to turn libgcc into a shared
library worried me so much.  The current libgcc.a contains some stuff
that IMHO isn't suitable to put into the shared libgcc.

Tightly controlling the libgcc.so ABI is extremely important.  The
SONAME of libgcc can *never* change (at least not without changing the
libc SONAME too) on Linux and the Hurd.  On the bright side these
systems use the complete GNU toolchain which means that we have a lot
more tools to avoid this than other platforms.

This discussion has far too much focussed on the question who'll have
to build the shared libgcc.  And that part of the discussion hasn't
been terribly productive.  And actually building a shared libgcc
*before* the GCC team is committed to mainting binary compatibility of
the stuff we're going to put into it is pointless.

Instead I'd like to start working with the GCC team on establishing an
ABI for that shared libgcc.  I could sure use some assistence on that
from GCC developers interested in Linux.

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jason R Thorpe]

On Fri, Jul 14, 2000 at 03:21:32PM +0100, Richard Earnshaw wrote:

 > This isn't quite true.  We don't install a shared libgcc on BSD platforms 
 > because libc has replacements for the most common libgcc functions built 
 > into it.  This is an equally disgusting hack because it assumes that the 
 > definitions in there will be sufficient even if the compiler is upgraded.  
 > I suspect it will cause even more problems moving forward when we need to 
 > include exception management support.

Err, which functions, specifically?  If you're talking about stuff
like __ashlsi3, the m68k ports have that stuff in libc mostly as
an historical accident (Utah put them in there in the HP-BSD days,
and they were just never really removed, even though libgcc has those
functions as well).

...or are you referring to something else?

(Serious question ... if I am misunderstanding this, I would like to
understand it better...)

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Earnshaw]

> On Fri, Jul 14, 2000 at 03:21:32PM +0100, Richard Earnshaw wrote:
> 
>  > This isn't quite true.  We don't install a shared libgcc on BSD platforms 
>  > because libc has replacements for the most common libgcc functions built 
>  > into it.  This is an equally disgusting hack because it assumes that the 
>  > definitions in there will be sufficient even if the compiler is upgraded.  
>  > I suspect it will cause even more problems moving forward when we need to 
>  > include exception management support.
> 
> Err, which functions, specifically?  If you're talking about stuff
> like __ashlsi3, the m68k ports have that stuff in libc mostly as
> an historical accident (Utah put them in there in the HP-BSD days,
> and they were just never really removed, even though libgcc has those
> functions as well).
> 
> ...or are you referring to something else?
> 
> (Serious question ... if I am misunderstanding this, I would like to
> understand it better...)
> 

Yes.  They are still there.  And because of the way shared libs work I 
believe they have to be.  Consider something like __divsi3 and then assume 
that it isn't in libc.so and that we don't have a shared libgcc.  There 
are two ways the linker could work:

1) The linker doesn't resolve symbols from shared libs into archives: If 
it is needed by libc.so and it weren't needed by the application the 
linker wouldn't put it into the application.  So we would get a run-time 
fault when the symbol isn't found.

2) The linker does resolve symbols from shared libs into archives: this 
would result in every symbol possibly needed by libc from libgcc getting 
put into the static part of the application even if it weren't needed for 
that application (the linker can't pick apart the dependencies of the 
shared lib).  This leads to code bloat since now we include __divsi3 in 
our app even if we never call it.

Now I think about it, I can't hand-on-heart say which is the way it really 
happens: I think it is the first; and even if it isn't the consequences 
aren't pretty.

R.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jason R Thorpe]

On Fri, Jul 14, 2000 at 05:46:22PM +0100, Richard Earnshaw wrote:

 > Yes.  They are still there.  And because of the way shared libs work I 
 > believe they have to be.  Consider something like __divsi3 and then assume 
 > that it isn't in libc.so and that we don't have a shared libgcc.  There 
 > are two ways the linker could work:
 > 
 > 1) The linker doesn't resolve symbols from shared libs into archives: If 
 > it is needed by libc.so and it weren't needed by the application the 
 > linker wouldn't put it into the application.  So we would get a run-time 
 > fault when the symbol isn't found.
 > 
 > 2) The linker does resolve symbols from shared libs into archives: this 
 > would result in every symbol possibly needed by libc from libgcc getting 
 > put into the static part of the application even if it weren't needed for 
 > that application (the linker can't pick apart the dependencies of the 
 > shared lib).  This leads to code bloat since now we include __divsi3 in 
 > our app even if we never call it.

Err... ok, now I think I'm confused.

Looking at NetBSD shared library build rules, we basically see what
amounts to:

	ld -x -shared -soname libc.so.12 -o libc.so.12.62 \
	    /usr/lib/crtbeginS.o \
	    --whole-archive libc_pic.a --no-while-archive \
	    /usr/lib/crtendS.o

Hm, are you referring to just the quad support library?  Otherwise,
what kinds of compiler support routines would libgcc be providing on
e.g. the Alpha?

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Richard Earnshaw]

> On Fri, Jul 14, 2000 at 05:46:22PM +0100, Richard Earnshaw wrote:
> 
>  > Yes.  They are still there.  And because of the way shared libs work I 
>  > believe they have to be.  Consider something like __divsi3 and then assume 
>  > that it isn't in libc.so and that we don't have a shared libgcc.  There 
>  > are two ways the linker could work:
>  > 
>  > 1) The linker doesn't resolve symbols from shared libs into archives: If 
>  > it is needed by libc.so and it weren't needed by the application the 
>  > linker wouldn't put it into the application.  So we would get a run-time 
>  > fault when the symbol isn't found.
>  > 
>  > 2) The linker does resolve symbols from shared libs into archives: this 
>  > would result in every symbol possibly needed by libc from libgcc getting 
>  > put into the static part of the application even if it weren't needed for 
>  > that application (the linker can't pick apart the dependencies of the 
>  > shared lib).  This leads to code bloat since now we include __divsi3 in 
>  > our app even if we never call it.
> 
> Err... ok, now I think I'm confused.
> 
> Looking at NetBSD shared library build rules, we basically see what
> amounts to:
> 
> 	ld -x -shared -soname libc.so.12 -o libc.so.12.62 \
> 	    /usr/lib/crtbeginS.o \
> 	    --whole-archive libc_pic.a --no-while-archive \
> 	    /usr/lib/crtendS.o
> 
> Hm, are you referring to just the quad support library?  Otherwise,
> what kinds of compiler support routines would libgcc be providing on
> e.g. the Alpha?
> 

Yes, these are really functions that should be part of libgcc. I suspect 
there is very little else needed on the Alpha, but consider the ARM.  For 
that you also need all the soft-float functions and __divsi3.  Currently 
we build these directly into libc.so so it looks like we have no 
dependency.  But if a new version of gcc were to introduce a new low-level 
function we would have to rebuild our libc.so to supply it, since 
otherwise any other shared library built with that new version of gcc 
might require that interface.

This is precisely the same argument as is being covered with glibc, except 
that we seem to have done what they are proposing already.  All the 
reasons that have been presented that it shouldn't be done there apply to 
NetBSD as well.

R.

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jason R Thorpe]

On Fri, Jul 14, 2000 at 06:22:56PM +0100, Richard Earnshaw wrote:

 > This is precisely the same argument as is being covered with glibc, except 
 > that we seem to have done what they are proposing already.  All the 
 > reasons that have been presented that it shouldn't be done there apply to 
 > NetBSD as well.

Ah, okay, now I understand the problem.  Thanks.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Geoff Keating]

> Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm
> Date: Fri, 14 Jul 2000 16:25:05 +0200
> From: Mark Kettenis <kettenis@wins.uva.nl>

[aoliva said:]
>    Now think of glibc: since it uses libgcc, it will also have some
>    particular libgcc SONAME encoded in it.  But libgcc already depended
>    on libc, so we have a circularity.  No big deal: each library will
>    only be loaded once, and everything is fine, right?  Despite the minor
>    problem of how to bootstrap this situation.

You can have circular dependencies involving libc.  libc is not needed at
program startup, ld.so includes everything it needs (it has to, since
it's responsible for loading libc anyway).

> Tightly controlling the libgcc.so ABI is extremely important.  The
> SONAME of libgcc can *never* change (at least not without changing the
> libc SONAME too) on Linux and the Hurd.  On the bright side these
> systems use the complete GNU toolchain which means that we have a lot
> more tools to avoid this than other platforms.

Yes, this is required.  I think it's a good idea for other platforms
too.

It doesn't require any special tools---to be precise, special tools
don't help.  

For instance, symbol versioning is to solve the problem of how to have
two functions named printf(), but this isn't needed for libgcc because
if we (say) want to change the interface of _adddi3, then we can just
call the new function _adddi3_2.

...
> And actually building a shared libgcc
> *before* the GCC team is committed to mainting binary compatibility of
> the stuff we're going to put into it is pointless.

> Instead I'd like to start working with the GCC team on establishing an
> ABI for that shared libgcc.  I could sure use some assistence on that
> from GCC developers interested in Linux.

The GCC team is already committed to binary compatibility with older
versions of gcc, like 2.95.2, so we could start with that.  In fact,
we have to start with that.

Now, what else would we like?  As a starting point, I think that if
we're going to change the frame.o ABI, we should change it to
something more future-proof.  Or do we want to export the eh.o ABI?
In that case we'd better wait for the new C++ ABI, too.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Date: Fri, 14 Jul 2000 12:44:29 -0700
   From: Geoff Keating <geoffk@cygnus.com>

   > Tightly controlling the libgcc.so ABI is extremely important.  The
   > SONAME of libgcc can *never* change (at least not without changing the
   > libc SONAME too) on Linux and the Hurd.  On the bright side these
   > systems use the complete GNU toolchain which means that we have a lot
   > more tools to avoid this than other platforms.

   Yes, this is required.  I think it's a good idea for other platforms
   too.

Sure :-).

   It doesn't require any special tools---to be precise, special tools
   don't help.

Well, we need the help from our tools on Linux to solve the the
problem with the frame functions living in glibc (versioning and
perhaps DT_AUXILIARY).

   For instance, symbol versioning is to solve the problem of how to have
   two functions named printf(), but this isn't needed for libgcc because
   if we (say) want to change the interface of _adddi3, then we can just
   call the new function _adddi3_2.

Which is so simple that it probably works for all platforms (although
you'd probably call it _adddi4 :-)).

   ...
   > And actually building a shared libgcc
   > *before* the GCC team is committed to mainting binary compatibility of
   > the stuff we're going to put into it is pointless.

   > Instead I'd like to start working with the GCC team on establishing an
   > ABI for that shared libgcc.  I could sure use some assistence on that
   > from GCC developers interested in Linux.

   The GCC team is already committed to binary compatibility with older
   versions of gcc, like 2.95.2, so we could start with that.  In fact,
   we have to start with that.

I'm afraid gcc 2.8 and the various egcs releases will have to be taken
into account, at least for various x86 targets, and at least for plain
C.  A lot of C++ devlopers still use egcs 1.1.2 since allegedly gcc
2.95.2 tends to produce too many ICE's.

Linking with older object files and static libraries isn't essential,
but interaction with shared libraries is.  But I think that's doable,
it just takes some time to do some field testing, the problem being
that stuff on development machines tends to be recompiled too often,
making it hard to find old libraries.

   Now, what else would we like?  As a starting point, I think that if
   we're going to change the frame.o ABI, we should change it to
   something more future-proof.  Or do we want to export the eh.o ABI?
   In that case we'd better wait for the new C++ ABI, too.

The frame.o (now mostly frame-dwarf2.o I guess) and
eh.o modules are coupled via __frame_state_for().  The problems that
more or less started this thread suggest that __frame_state_for() was
(accidently) regarded as an internal interface.  In that case the
frame.o and eh.o modules have to match, and the EH ABI would have to
be fixed as well.

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Nix]

Richard Henderson <rth@cygnus.com> writes:

>                               The barrier is the amount of horror I
> feel in trying to figure out libtool in a (canadian) cross environment.

Until recently, it was rather broken because of some host/target
confusion. But as long as you have

2000-06-17  Syd Polk  <spolk@redhat.com>

	* libtool.m4 (AC_LIBTOOL_SETUP): Do not generate a libtool based
	on target; use host instead.

applied, even libtool-1.3.x works.

(I spotted that on 2000-06-19 and was rather chuffed to find Syd'd fixed
 it two days before... serendipity, or the morphic field? ;) Bugs that
 have already been fixed are the best kind of bugs.)

-- 
`I can guarantee it's no problem in my network, and if I don't get some
 sleep soon, I'll guarantee it will become a problem in your network.'
     --- Chris `Saundo' Saunderson deals with a late-night phone call

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Alexandre Oliva]

On Jul 14, 2000, Geoff Keating <geoffk@cygnus.com> wrote:

> [aoliva said:]

>> Despite the minor problem of how to bootstrap this situation.

> You can have circular dependencies involving libc.

Yup.  I was talking about how to *create* the libraries in such a way
that each one uses the appropriate SONAME to refer to the other.  As I
said, no big deal, it just has to be done carefully.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Mon, Jul 17, 2000 at 05:59:22AM -0300, Alexandre Oliva wrote:
> On Jul 14, 2000, Geoff Keating <geoffk@cygnus.com> wrote:
> 
> > [aoliva said:]
> 
> >> Despite the minor problem of how to bootstrap this situation.
> 
> > You can have circular dependencies involving libc.
> 
> Yup.  I was talking about how to *create* the libraries in such a way
> that each one uses the appropriate SONAME to refer to the other.  As I
> said, no big deal, it just has to be done carefully.
> 

I am doing some experiments on the shared libgcc. I have added
-Wl,--auxiliary,libgcc.so.3 when building my libc.so. I created a
shell script, updatelibgcc. updatelibgcc takes CC and slibdir from
environment to build/install libgcc.so.3. It seems to work so far.

One interesting thing I noticed that libgcc.so might not be needed
at all under Linux. I don't like the explicit dependency on libgcc.so.
Can someone tell me if there is a case --auxiliary libgcc.so.3 is not
enough for Linux? I may have missed something.

Thanks.

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

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Mark Kettenis]

   Date: Mon, 17 Jul 2000 09:13:20 -0700
   From: "H . J . Lu" <hjl@valinux.com>
   Cc: Geoff Keating <geoffk@cygnus.com>, kettenis@wins.uva.nl,
      drepper@cygnus.com, law@cygnus.com, rth@twiddle.net,
      libc-hacker@sourceware.cygnus.com, gcc@gcc.gnu.org
   Content-Disposition: inline
   User-Agent: Mutt/1.2.2i
   Content-Type: text/plain; charset=us-ascii

   On Mon, Jul 17, 2000 at 05:59:22AM -0300, Alexandre Oliva wrote:
   > On Jul 14, 2000, Geoff Keating <geoffk@cygnus.com> wrote:
   > 
   > > [aoliva said:]
   > 
   > >> Despite the minor problem of how to bootstrap this situation.
   > 
   > > You can have circular dependencies involving libc.
   > 
   > Yup.  I was talking about how to *create* the libraries in such a way
   > that each one uses the appropriate SONAME to refer to the other.  As I
   > said, no big deal, it just has to be done carefully.
   > 

   I am doing some experiments on the shared libgcc. I have added
   -Wl,--auxiliary,libgcc.so.3 when building my libc.so. I created a
   shell script, updatelibgcc. updatelibgcc takes CC and slibdir from
   environment to build/install libgcc.so.3. It seems to work so far.

   One interesting thing I noticed that libgcc.so might not be needed
   at all under Linux. I don't like the explicit dependency on libgcc.so.
   Can someone tell me if there is a case --auxiliary libgcc.so.3 is not
   enough for Linux? I may have missed something.

Let me refresh your mind:

 1. We have __deregister_frame_info, __register_frame_info,
    __frame_state_for, etc. in libc.so.

 2. A single copy of these functions must be used in every program.

 3. It might be necessary to change the implementation (while
    maintaining backwards compatibility) of these functions to support
    new versions of GCC.  This implies that the single copy mentioned
    above must be the most recent copy.

 4. We don't want to force everybody to recompile or even upgrade libc
    whenever they install a new version of GCC.

The only reliable solution that has been found thus far is putting
these functions in a shared library that can be upgraded (in principle
when installing a new version of GCC) whenever needed.

Now if point 3 above includes adding any new interfaces, having that
shared library as a DT_AUXILIARY of libc.so isn't enough.  Any objects
that make use of that new functionality (presumably because they have
been compiled with the new GCC) will have to be explicitly linked with
that shared library.

The EH frame info issue isn't the only problem with the current
libgcc.a that might be solved by introducing a shared libgcc.  Right
now symbols from libgcc.a that are used in code in a shared library
(say libfoo.so) are usually reexported from that shared library.

This means that binaries linked against libfoo.so that also
need those symbols, contain undefined references to those symbols.
Now if you change the implementation of libfoo.so such that it doesn't
need those symbols from libgcc.a anymore and install this new version
(that's otherwise supposed to be still binary compatible) your program
won't run anymore.

The solution proposed by the GCC folks is simply to put everything in
libgcc.a into libgcc.so and link every program or shared library with
libgcc.so.  This indeed guarentees that you never see this problem,
and is likely to work on most platforms that support shared libraries.
Unfortunately this introduces an explicit dependency for every program
on yet another shared library.  There have been several people who
said they didn't like that, myself included.  Having to distribute a
shared library with all binaries is a PITA and might lead to people
statically linking their programs to avoid this.  There also may be of
performance penalty with using the libgcc functions from a shared
library

I think that with on Linux and the Hurd, with the current GNU tools we
can do a little better.  The reexportation problem can be controlled
using STV_HIDDEN/STV_PROTECTED.

Mark

Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[H . J . Lu]

On Tue, Jul 18, 2000 at 06:20:38PM +0200, Mark Kettenis wrote:
> 
>    I am doing some experiments on the shared libgcc. I have added
>    -Wl,--auxiliary,libgcc.so.3 when building my libc.so. I created a
>    shell script, updatelibgcc. updatelibgcc takes CC and slibdir from
>    environment to build/install libgcc.so.3. It seems to work so far.
> 
>    One interesting thing I noticed that libgcc.so might not be needed
>    at all under Linux. I don't like the explicit dependency on libgcc.so.
>    Can someone tell me if there is a case --auxiliary libgcc.so.3 is not
>    enough for Linux? I may have missed something.
> 
> Let me refresh your mind:
> 
>  1. We have __deregister_frame_info, __register_frame_info,
>     __frame_state_for, etc. in libc.so.
> 
>  2. A single copy of these functions must be used in every program.
> 
>  3. It might be necessary to change the implementation (while
>     maintaining backwards compatibility) of these functions to support
>     new versions of GCC.  This implies that the single copy mentioned
>     above must be the most recent copy.
> 
>  4. We don't want to force everybody to recompile or even upgrade libc
>     whenever they install a new version of GCC.
> 
> The only reliable solution that has been found thus far is putting
> these functions in a shared library that can be upgraded (in principle
> when installing a new version of GCC) whenever needed.

Guess what, that shared library has been there for a long time. It is
called libstdc++.so. Why do we need libgcc.so when libstdc++.so is
there? I noticed the problem with the shared libstdc++ v3. But I
found out it was caused by libtool:

http://gcc.gnu.org/ml/gcc-patches/2000-07/msg00707.html

You may ask what if I don't use the shared libstdc++. It is fine since 
you are using static EH functions in libgcc as far as libgcc is
concerned since those EH functions are pulled in from libgcc.a by the
linker.

Currently, glibc doesn't use exceptions. As long as the ABI of those
frame functions are unchanged, glibc should be ok. Right now, only
ia64 is broken due to the new fields in "struct object". My suggestions
for glibc are:

1. Fix "struct object" in elf/soinit.c. A glibc ABI will be nice.
2. Fix libtool and shared libstdc++ v3 so that we can use it as the
shared library for thos EH functions.

We can take another look at the shared libgcc issue when the EH is used
in glibc. We will make a decision then. I don't think we need it now.



H.J.