Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Jack Howarth]

   Since neither HJ or Franz has posted yet, I thought I would mention
that we seem to have the libgcc situation resolved for gcc 3.2 on ppc
without resorting to changes in gcc 3.2. The previous patch Franz had
proposed using a sysdeps/powerpc/libgcc-compat.S in glibc-2-2-branch
(which prevents the any libgcc-compat symbols from being exported by
libc for linking), now works with the binutils fixes HJ has done this
week...

http://sources.redhat.com/ml/binutils/2002-08/msg00175.html
http://sources.redhat.com/ml/binutils/2002-08/msg00217.html

I believe Franz is hoping that HJ will do a new binutils rev
before gcc 3.2 is released so we can document the binutils
requirements on ppc. Thanks again to HJ for all his help.
                            Jack

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Jack Howarth]

Franz,
    I think it would be helpful if we reviewed the discussion in the
past in light of the recent binutils fixes. In particular, see message...

http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00374.html

Jakub's suggestion that...

> I thought glibc was exporting those at a different version on ppc. Now
> that I see it is @@GLIBC_2.0, I really don't see why it should be moved to
> GCC_3.0 symver unless this is for pure esthetical reasons, you just
> eventually remove @@GLIBC_2.0 export from glibc and convert that to
> @GLIBC_2.0. Libraries linked with -lc -lgcc_s would still work (they can
> choose whether they'll use the symbols from glibc or libgcc_s), libraries
> linked with -lc -lgcc (horribly broken) can still be satisfied with the
> future @GLIBC_2.0 export from glibc.

is now valid as the linker no longer complains about duplicate 
__divdi3@GLIBC_2.0 symbols when using the current libgcc-compat
code in glibc-2-2-branch in a gcc 2.95.4 or 3.1.1/3.2 built glibc
to build new programs with gcc 2.95.4. 
    Assuming that issue is fixed, can you help define situations where
pre-existing binaries will break when runing a glibc with the current
libgcc-compat code in glibc-2-2-branch. I haven't seen this situation
occur on debian ppc sid when I ran either a gcc 2.95.4 built or 3.1.1.
built glibc with the libgcc-compat changes from glibc-2-2-branch.
In short I am wondering what level of breakage really still exists if 
any?
                        Jack

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Jack Howarth]

Jakub,
    When you said...

This is not how the linker works.
When building libgcc_s, -lc comes after all the libgcc/./*{div,mod}di3.o
which means the symbols are exported from both glibc and
libgcc_s (with the same version):
On IA-32 where gcc has been built a couple of times since that glibc was
installed:
$ readelf -s /lib/libc.so.6 | grep moddi3
   701: 00016ad0    55 FUNC    GLOBAL DEFAULT   11 __umoddi3@@GLIBC_2.0
  1856: 00016a10   128 FUNC    GLOBAL DEFAULT   11 __moddi3@@GLIBC_2.0
$ readelf -s /lib/libgcc_s.so.1 | grep moddi3
    46: 00002788    38 FUNC    GLOBAL DEFAULT   11 __umoddi3@@GLIBC_2.0
    95: 000021c0   240 FUNC    GLOBAL DEFAULT   11 __moddi3@@GLIBC_2.0
So either you run into yet another linker bug, or you have
some pieces of your patch applied to the gcc tree you were testing.

...what did you mean by another linker bug. We did in fact run into
a linker bug where using Franz's new revised libgcc-compat patches
and gcc 2.95.4 to build programs, we did indeed run into symbol conflicts
in binutils. HJ Lu has test cased this situation and fixed it in binutils
cvs...

http://sources.redhat.com/ml/binutils/2002-08/msg00190.html
http://sources.redhat.com/ml/binutils/2002-08/msg00180.html
http://sources.redhat.com/ml/binutils/2002-08/msg00175.html

I have locally confirmed this binutils change eliminates the
problem and I can now use a glibc with Franz's new libgcc-compat
changes to build programs with gcc 2.95.4 without symbol conflicts.
I have also built gcc 3.2 with Franz's proposed symbol versioning
fixup against the same glibc 2.2.5 (with new libgcc-compat patches)
and the new patched binutils. The resulting gcc 3.2 builds fine and
passes make check fine as well. I don't think we have to worry about
breakage now but rather if the change in symbol versioning is merited.
                          Jack

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Montag, 12. August 2002 21:51, Richard Henderson wrote:
> On Mon, Aug 12, 2002 at 03:30:15PM -0400, Jakub Jelinek wrote:
> > > > 1. do nothing:
> > > > 	This leaves use with linktime version for the divmod functions in
> > > > both glibc and libgcc_s, which everybody seems to agree that this is
> > > > a bad idea.
> >
> > #1 seems like the preferred choice when the symbol versions are identical
> > IMNSHO.
>
> Exactly.  I've still not heard a *coherent* explanation
> of why any change is needed.  Only several incomplete
> explanations.

Uhm, what was incoherent about my last explanation?

But it general it's _extremely_ hard for me to find the right words on this 
issue, simply because I don't know them when it comes to binutils issues as a 
non-native speaker. Additionally I seem to wade in a maze of binutils bugs, 
which makes it hard for to tell the real culprits.

So, with the current binutils state I see the following facts:

1. exporting these symbols both from glibc and libgcc_s with linktime 
reference is a bug and causes undefined symbols when running gcc3.1 compiled 
binaries on a gcc2 compiled glibc (even if libgcc_s is distributed with the 
binary!)
2. if I demote the symbols in glibc to a runtime reference as Jakub suggested, 
gcc fails to build a correct libgcc_s

Now, since nobody is answering me with any hints, what else do you expect me 
to do?

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Richard Henderson]

On Mon, Aug 12, 2002 at 03:30:15PM -0400, Jakub Jelinek wrote:
> > > 1. do nothing:
> > > 	This leaves use with linktime version for the divmod functions in both
> > > 	glibc and libgcc_s, which everybody seems to agree that this is a bad
> > > idea.
> 
> #1 seems like the preferred choice when the symbol versions are identical
> IMNSHO.

Exactly.  I've still not heard a *coherent* explanation
of why any change is needed.  Only several incomplete
explanations.


r~

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Montag, 12. August 2002 21:30, Jakub Jelinek wrote:
> On Fri, Aug 09, 2002 at 08:55:37PM +0200, Franz Sirl wrote:
> > On Mittwoch, 7. August 2002 19:16, Franz Sirl wrote:
> > > So what happened? I think we are hosed, cause we violated Uli's "Golden
> > > Rule" for version scripts on Linux: "On Linux, don't use a version
> > > script to attach versions to symbols, only use it to decide if a symbol
> > > pre-versioned with .symver should be local or global."
> > > Cause libgcc_s is linked against glibc, the linker decides to leave the
> > > divmod functions in libgcc_s local, because they already exist with the
> > > same version and global in glibc.
>
> This is not how the linker works.
> When building libgcc_s, -lc comes after all the libgcc/./*{div,mod}di3.o
> which means the symbols are exported from both glibc and
> libgcc_s (with the same version):
> On IA-32 where gcc has been built a couple of times since that glibc was
> installed:
> $ readelf -s /lib/libc.so.6 | grep moddi3
>    701: 00016ad0    55 FUNC    GLOBAL DEFAULT   11 __umoddi3@@GLIBC_2.0
>   1856: 00016a10   128 FUNC    GLOBAL DEFAULT   11 __moddi3@@GLIBC_2.0

As I said, I fixed glibc as you suggested to use a runtime only export, so I 
have @GLIBC_2.0 now.

> $ readelf -s /lib/libgcc_s.so.1 | grep moddi3
>     46: 00002788    38 FUNC    GLOBAL DEFAULT   11 __umoddi3@@GLIBC_2.0
>     95: 000021c0   240 FUNC    GLOBAL DEFAULT   11 __moddi3@@GLIBC_2.0
> So either you run into yet another linker bug, or you have
> some pieces of your patch applied to the gcc tree you were testing.

I verified that my gcc tree is clean in that respect and I upgraded to the 
latest hjl binutils to be sure, same problem. libgcc_s doesn't get a version 
attached for the 4 symbols affected, and as I understood Uli, you shouldn't 
use a version script to try to _attach_ versions to symbols, which makes me 
believe this is more or less expected.

> > > Now lets see what options we have on PPC:
> > >
> > > 1. do nothing:
> > > 	This leaves use with linktime version for the divmod functions in both
> > > 	glibc and libgcc_s, which everybody seems to agree that this is a bad
> > > idea.
>
> #1 seems like the preferred choice when the symbol versions are identical
> IMNSHO.

Hmmm, iff it's a binutils bug I might agree to close this discussion, even 
though it only entered gcc mistakenly.

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Jakub Jelinek]

On Fri, Aug 09, 2002 at 08:55:37PM +0200, Franz Sirl wrote:
> On Mittwoch, 7. August 2002 19:16, Franz Sirl wrote:
> > So what happened? I think we are hosed, cause we violated Uli's "Golden
> > Rule" for version scripts on Linux: "On Linux, don't use a version script
> > to attach versions to symbols, only use it to decide if a symbol
> > pre-versioned with .symver should be local or global."
> > Cause libgcc_s is linked against glibc, the linker decides to leave the
> > divmod functions in libgcc_s local, because they already exist with the
> > same version and global in glibc.

This is not how the linker works.
When building libgcc_s, -lc comes after all the libgcc/./*{div,mod}di3.o
which means the symbols are exported from both glibc and
libgcc_s (with the same version):
On IA-32 where gcc has been built a couple of times since that glibc was
installed:
$ readelf -s /lib/libc.so.6 | grep moddi3
   701: 00016ad0    55 FUNC    GLOBAL DEFAULT   11 __umoddi3@@GLIBC_2.0
  1856: 00016a10   128 FUNC    GLOBAL DEFAULT   11 __moddi3@@GLIBC_2.0
$ readelf -s /lib/libgcc_s.so.1 | grep moddi3
    46: 00002788    38 FUNC    GLOBAL DEFAULT   11 __umoddi3@@GLIBC_2.0
    95: 000021c0   240 FUNC    GLOBAL DEFAULT   11 __moddi3@@GLIBC_2.0
So either you run into yet another linker bug, or you have
some pieces of your patch applied to the gcc tree you were testing.

>
> > Now lets see what options we have on PPC:
> >
> > 1. do nothing:
> > 	This leaves use with linktime version for the divmod functions in both
> > 	glibc and libgcc_s, which everybody seems to agree that this is a bad
> > idea.

#1 seems like the preferred choice when the symbol versions are identical
IMNSHO.

	Jakub

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Freitag, 9. August 2002 20:55, Franz Sirl wrote:
> Richard,
>
> no comments on that?

Why do I get no reply? I'm locked out, I can't fix glibc if gcc isn't fixed!

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Jack Howarth]

Richard,
   The problems Franz and I saw building programs after glibc was changed
to Franz's new libgcc-compat changes (which match his proposed fixup
for symbol versioning) are now gone. We were tickling a bug in binutils
which H.J. Lu has kindly fixed for us...

http://sources.redhat.com/ml/binutils/2002-08/msg00175.html

Is there still time to get Franz's fixup for symbol versioning...

http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00252.html

...into gcc 3.2?
                              Jack

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Mittwoch, 7. August 2002 19:16, Franz Sirl wrote:
> So what happened? I think we are hosed, cause we violated Uli's "Golden
> Rule" for version scripts on Linux: "On Linux, don't use a version script
> to attach versions to symbols, only use it to decide if a symbol
> pre-versioned with .symver should be local or global."
> Cause libgcc_s is linked against glibc, the linker decides to leave the
> divmod functions in libgcc_s local, because they already exist with the
> same version and global in glibc.
>
> Now lets see what options we have on PPC:
>
> 1. do nothing:
> 	This leaves use with linktime version for the divmod functions in both
> 	glibc and libgcc_s, which everybody seems to agree that this is a bad
> idea.
>
> 2. change only the divmod functions in glibc to runtime references, leave
> gcc as it is:
> 	This seems to trigger a linker bug on one side ("defined both in glibc and
> 	libgcc_s), but even if this problem is fixed, we will run into the problem
> 	described above.
>
> 3. do as I suggested:
> 	This will untwist the divmod functions in glibc and libgcc_s and I
> couldn't find any drawbacks so far.
>
> Well, you won't be surprised if I vote for #3 :-). Even more, I now think
> my patch should be more generic and apply to all Linux platforms which have
> to maintain compatibility with gcc2 compiled binaries. Because if we have a
> generic config/divmod-symver.h, we can correctly use .symver as Uli
> strongly suggests.

Richard,

no comments on that?

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Mittwoch, 7. August 2002 02:32, Richard Henderson wrote:
> On Wed, Aug 07, 2002 at 12:22:01AM +0200, Franz Sirl wrote:
> > As explained in an earlier message, if you deliver your c++ app
> > together with libgcc_s and use it on on a gcc-2.95 compiled glibc,
> > the app may not run because of missing symbol versions.
>
> This is my sticking point.  This explanation is not detailed enough.
> *WHY* is the symbol version missing?  Why does the version of gcc
> that compiled glibc affect the set of symbols exported from glibc
> in any way?

There is no released version of glibc which exports these symbols with 
versions, but we need to add runtime versions unless we want to break old 
binaries when a gcc3.[12] compiled glibc is installed.

> > Maybe I should ask a question myself, what is the reason for this strange
> > setup on all linux platforms that don't override it? Why is
> > config/libgcc-glibc.ver done this way?
>
> Because I thought all existing glibc ports did things the same way
> that x86 did, and that even if they didn't, that it didn't make any
> difference what version tag was attached to these symbols.

No, so far it seems x86 was the exception.

Now, more confusing data:

On entropy I installed gcc-3.2 with my patch. So the divmod versions on 
entropy look like this:

[fsirl@entropy:~]$ nm -g /lib/libc-2.2.90.so |grep divdi3
0001c214 T __divdi3@GLIBC_2.0
0001c308 T __udivdi3@GLIBC_2.0
[fsirl@entropy:~]$ nm -g /lib/libgcc_s.so.1 |grep divdi3
00009524 T __divdi3@@GCC_3.0
00009524 T __divdi3@GLIBC_2.0
0000a070 T __udivdi3@@GCC_3.0
0000a070 T __udivdi3@GLIBC_2.0

Now, for further testing, I decided to build another gcc-3.2 RPM without my 
versions patch. Now see how the newly built libgcc_s.so.1 looks like:

[fsirl@entropy:~/TC/gcc/BUILD/obj-gcc32-ppc/gcc]$ nm -g libgcc_s.so.1 |grep 
divdi3
[fsirl@entropy:~/TC/gcc/BUILD/obj-gcc32-ppc/gcc]$

Huh, nothing? Lets try another symbol:

[fsirl@entropy:~/TC/gcc/BUILD/obj-gcc32-ppc/gcc]$ nm -g libgcc_s.so.1 |grep 
ashrdi3
00001a90 T __ashrdi3

Hmm, looks good, lets try readelf:

[fsirl@entropy:~/TC/gcc/BUILD/obj-gcc32-ppc/gcc]$ readelf -a libgcc_s.so.1 
|grep divdi3
   241: 000025b0   220 FUNC    LOCAL  DEFAULT   10 __divdi3
   284: 000030fc    36 FUNC    LOCAL  DEFAULT   10 __udivdi3

Ah, probably I didn't revert my patch correctly, lets check the map file:

[fsirl@entropy:~/TC/gcc/BUILD/obj-gcc32-ppc/gcc]$ head  libgcc/libgcc.map
GLIBC_2.0 {
  global:
        __register_frame_table;
        __deregister_frame_info;
        __register_frame_info_table;
        __register_frame_info;
        __udivdi3;
        __umoddi3;
        __divdi3;
        __moddi3;

No, everything is perfect! (No, it's also not listed under GCC_3.0, in case 
you ask)

So what happened? I think we are hosed, cause we violated Uli's "Golden Rule" 
for version scripts on Linux: "On Linux, don't use a version script to attach 
versions to symbols, only use it to decide if a symbol pre-versioned with 
.symver should be local or global."
Cause libgcc_s is linked against glibc, the linker decides to leave the divmod 
functions in libgcc_s local, because they already exist with the same version 
and global in glibc.

Now lets see what options we have on PPC:

1. do nothing:
	This leaves use with linktime version for the divmod functions in both
	glibc and libgcc_s, which everybody seems to agree that this is a bad idea.

2. change only the divmod functions in glibc to runtime references, leave gcc 
as it is:
	This seems to trigger a linker bug on one side ("defined both in glibc and
	libgcc_s), but even if this problem is fixed, we will run into the problem
	described above.

3. do as I suggested:
	This will untwist the divmod functions in glibc and libgcc_s and I couldn't
	find any drawbacks so far.

Well, you won't be surprised if I vote for #3 :-). Even more, I now think my 
patch should be more generic and apply to all Linux platforms which have to 
maintain compatibility with gcc2 compiled binaries. Because if we have a 
generic config/divmod-symver.h, we can correctly use .symver as Uli strongly 
suggests.

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Richard Henderson]

On Wed, Aug 07, 2002 at 12:22:01AM +0200, Franz Sirl wrote:
> As explained in an earlier message, if you deliver your c++ app
> together with libgcc_s and use it on on a gcc-2.95 compiled glibc,
> the app may not run because of missing symbol versions.

This is my sticking point.  This explanation is not detailed enough.
*WHY* is the symbol version missing?  Why does the version of gcc
that compiled glibc affect the set of symbols exported from glibc
in any way?

> Maybe I should ask a question myself, what is the reason for this strange 
> setup on all linux platforms that don't override it? Why is 
> config/libgcc-glibc.ver done this way?

Because I thought all existing glibc ports did things the same way
that x86 did, and that even if they didn't, that it didn't make any
difference what version tag was attached to these symbols.


r~

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Mittwoch, 7. August 2002 00:01, Richard Henderson wrote:
> On Tue, Aug 06, 2002 at 11:41:56PM +0200, Franz Sirl wrote:
> > Huh? "just to shift"? I don't understand, I've already seen bugs
> > caused by the current setup...
>
> Then I still don't understand.  If either libc.so or libgcc_s.so
> exports the link-time version, and both export the runtime version,
> then the symbol should be resolvable from either library.

As explained in an earlier message, if you deliver your c++ app together with 
libgcc_s and use it on on a gcc-2.95 compiled glibc, the app may not run 
because of missing symbol versions. That happened with the OpenOffice/mozilla 
bundle cause still a lot of shared libs are wrongly compiled with -lc -lgcc, 
either hardcoded or because libtool does so (kde3 for example).

That wouldn't happen if the gcc version would be easily distinguashable from 
the glibc version and glibc doesn't export them as a linktime reference.

Maybe I should ask a question myself, what is the reason for this strange 
setup on all linux platforms that don't override it? Why is 
config/libgcc-glibc.ver done this way?

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Richard Henderson]

On Tue, Aug 06, 2002 at 11:41:56PM +0200, Franz Sirl wrote:
> Huh? "just to shift"? I don't understand, I've already seen bugs
> caused by the current setup...

Then I still don't understand.  If either libc.so or libgcc_s.so
exports the link-time version, and both export the runtime version,
then the symbol should be resolvable from either library.


r~

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Richard Henderson]

On Tue, Aug 06, 2002 at 11:47:00PM +0200, Franz Sirl wrote:
> Doesn't that setup cause the linker to complain like that:
> 
> /lib/libgcc_s.so.1(*IND*+0x0): multiple definition of `__divdi3@GLIBC_2.0'
> /lib/libc.so.6(.text+0x574): first defined here
> 
> I think that's what I've seen when I tried that, iirc.

If so, that is a bug.  This shouldn't cause a problem any
more than having the symbol "foo" in both libraries.


r~

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[H. J. Lu]

On Tue, Aug 06, 2002 at 11:47:00PM +0200, Franz Sirl wrote:
> On Dienstag, 6. August 2002 23:23, Jakub Jelinek wrote:
> > On Tue, Aug 06, 2002 at 11:13:10PM +0200, Franz Sirl wrote:
> > > But I don't want these symbols to resolve to the glibc versions, except
> > > for backwards compatibility. They should resolve to libgcc_s and should
> > > clearly state that. As stated in a followup message, the current setup
> > > already caused problems and I want to avoid this problems once and
> > > forever. 3.2 is the ideal candidate for such a change.
> > >
> > > So in the future glibc will export these symbols only as a runtime
> > > reference __divdi3@GLIBC_2.0 and libgcc_s will contain the linktime
> > > reference @@GCC_3.0 and the runtime reference @GLIBC_2.0. IMHO this is
> > > how it always should have
> >
> > I thought glibc was exporting those at a different version on ppc. Now
> > that I see it is @@GLIBC_2.0, I really don't see why it should be moved to
> > GCC_3.0 symver unless this is for pure esthetical reasons, you just
> > eventually remove @@GLIBC_2.0 export from glibc and convert that to
> > @GLIBC_2.0. Libraries linked with -lc -lgcc_s would still work (they can
> > choose whether they'll use the symbols from glibc or libgcc_s), libraries
> > linked with -lc -lgcc (horribly broken) can still be satisfied with the
> > future @GLIBC_2.0 export from glibc.
> 
> Doesn't that setup cause the linker to complain like that:
> 
> /lib/libgcc_s.so.1(*IND*+0x0): multiple definition of `__divdi3@GLIBC_2.0'
> /lib/libc.so.6(.text+0x574): first defined here

That can be a linker bug. I will see if I can come up with a small
testcase and fix it.


H.J.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Dienstag, 6. August 2002 23:23, Jakub Jelinek wrote:
> On Tue, Aug 06, 2002 at 11:13:10PM +0200, Franz Sirl wrote:
> > But I don't want these symbols to resolve to the glibc versions, except
> > for backwards compatibility. They should resolve to libgcc_s and should
> > clearly state that. As stated in a followup message, the current setup
> > already caused problems and I want to avoid this problems once and
> > forever. 3.2 is the ideal candidate for such a change.
> >
> > So in the future glibc will export these symbols only as a runtime
> > reference __divdi3@GLIBC_2.0 and libgcc_s will contain the linktime
> > reference @@GCC_3.0 and the runtime reference @GLIBC_2.0. IMHO this is
> > how it always should have
>
> I thought glibc was exporting those at a different version on ppc. Now
> that I see it is @@GLIBC_2.0, I really don't see why it should be moved to
> GCC_3.0 symver unless this is for pure esthetical reasons, you just
> eventually remove @@GLIBC_2.0 export from glibc and convert that to
> @GLIBC_2.0. Libraries linked with -lc -lgcc_s would still work (they can
> choose whether they'll use the symbols from glibc or libgcc_s), libraries
> linked with -lc -lgcc (horribly broken) can still be satisfied with the
> future @GLIBC_2.0 export from glibc.

Doesn't that setup cause the linker to complain like that:

/lib/libgcc_s.so.1(*IND*+0x0): multiple definition of `__divdi3@GLIBC_2.0'
/lib/libc.so.6(.text+0x574): first defined here

I think that's what I've seen when I tried that, iirc.

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Dienstag, 6. August 2002 23:25, Richard Henderson wrote:
> On Tue, Aug 06, 2002 at 11:13:10PM +0200, Franz Sirl wrote:
> > So in the future glibc will export these symbols only as a runtime
> > reference __divdi3@GLIBC_2.0 and libgcc_s will contain the linktime
> > reference @@GCC_3.0 and the runtime reference @GLIBC_2.0. IMHO this is
> > how it always should have been (and is for all other similar libgcc_s
> > symbols) on PPC. Unless one can give me a good explanation for the
> > current setup, I would rather prefer to have a correct setup on PPC for
> > the future.
>
> This is, IMO, a case of "you can't have your cake and eat it too".
> You should either change things and break compatibility or don't do
> anything at all.  Shifting symbols between versions just to shift
> them is pointless.

Huh? "just to shift"? I don't understand, I've already seen bugs caused by the 
current setup and I want to move to the new setup to cure these potential 
bugs for the future. And if I can do that easily with backwards 
compatibility, why should I break it? But if nothing else is acceptable to 
you, I would even prefer that.

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Richard Henderson]

On Tue, Aug 06, 2002 at 11:13:10PM +0200, Franz Sirl wrote:
> So in the future glibc will export these symbols only as a runtime reference 
> __divdi3@GLIBC_2.0 and libgcc_s will contain the linktime reference @@GCC_3.0 
> and the runtime reference @GLIBC_2.0. IMHO this is how it always should have 
> been (and is for all other similar libgcc_s symbols) on PPC. Unless one can 
> give me a good explanation for the current setup, I would rather prefer to 
> have a correct setup on PPC for the future.

This is, IMO, a case of "you can't have your cake and eat it too".
You should either change things and break compatibility or don't do
anything at all.  Shifting symbols between versions just to shift
them is pointless.


r~

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Jakub Jelinek]

On Tue, Aug 06, 2002 at 11:13:10PM +0200, Franz Sirl wrote:
> But I don't want these symbols to resolve to the glibc versions, except for 
> backwards compatibility. They should resolve to libgcc_s and should clearly 
> state that. As stated in a followup message, the current setup already caused 
> problems and I want to avoid this problems once and forever. 3.2 is the ideal 
> candidate for such a change.
> 
> So in the future glibc will export these symbols only as a runtime reference 
> __divdi3@GLIBC_2.0 and libgcc_s will contain the linktime reference @@GCC_3.0 
> and the runtime reference @GLIBC_2.0. IMHO this is how it always should have 

I thought glibc was exporting those at a different version on ppc. Now
that I see it is @@GLIBC_2.0, I really don't see why it should be moved to
GCC_3.0 symver unless this is for pure esthetical reasons, you just eventually
remove @@GLIBC_2.0 export from glibc and convert that to @GLIBC_2.0.
Libraries linked with -lc -lgcc_s would still work (they can choose whether
they'll use the symbols from glibc or libgcc_s), libraries linked with -lc -lgcc
(horribly broken) can still be satisfied with the future @GLIBC_2.0 export
from glibc.

	Jakub

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Dienstag, 6. August 2002 22:49, Richard Henderson wrote:
> On Tue, Aug 06, 2002 at 10:45:11PM +0200, Franz Sirl wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2002-08/subjects.html#00357
> >
> > The problem is that glibc also exports these 4
> > symbols with link-time reference (fixing that will be a follow-up patch)
> > and there are still a bunch of apps that manually link shared libs with
> > -lc -lgcc (like openssl, KDE, mozilla, etcetc) instead of -lgcc -lc -lgcc
> > or using gcc to link. That caused an undefined reference for
> > __divdi3@GLIBC_2.0 when running on a gcc2 compiled glibc, even though
> > libgcc_s.so was delivered with the app.
>
> So libc.so exports __divdi3@@GLIBC_2.0, but we're not matching
> that somehow?  I'm confused.  If libgcc_s exports these symbols
> with the same version tag, then they should be resolvable by
> either library, correct?

But I don't want these symbols to resolve to the glibc versions, except for 
backwards compatibility. They should resolve to libgcc_s and should clearly 
state that. As stated in a followup message, the current setup already caused 
problems and I want to avoid this problems once and forever. 3.2 is the ideal 
candidate for such a change.

So in the future glibc will export these symbols only as a runtime reference 
__divdi3@GLIBC_2.0 and libgcc_s will contain the linktime reference @@GCC_3.0 
and the runtime reference @GLIBC_2.0. IMHO this is how it always should have 
been (and is for all other similar libgcc_s symbols) on PPC. Unless one can 
give me a good explanation for the current setup, I would rather prefer to 
have a correct setup on PPC for the future.

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Richard Henderson]

On Tue, Aug 06, 2002 at 10:45:11PM +0200, Franz Sirl wrote:
> http://gcc.gnu.org/ml/gcc-patches/2002-08/subjects.html#00357
>
> The problem is that glibc also exports these 4
> symbols with link-time reference (fixing that will be a follow-up patch) and
> there are still a bunch of apps that manually link shared libs with -lc -lgcc
> (like openssl, KDE, mozilla, etcetc) instead of -lgcc -lc -lgcc or using gcc
> to link. That caused an undefined reference for __divdi3@GLIBC_2.0 when
> running on a gcc2 compiled glibc, even though libgcc_s.so was delivered with
> the app.

So libc.so exports __divdi3@@GLIBC_2.0, but we're not matching
that somehow?  I'm confused.  If libgcc_s exports these symbols
with the same version tag, then they should be resolvable by 
either library, correct?


r~

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Dienstag, 6. August 2002 22:29, Richard Henderson wrote:
> On Tue, Aug 06, 2002 at 09:23:58PM +0200, Franz Sirl wrote:
> > 	* gcc/Makefile.in (LIB2_DIVMOD_ST_SH_FUNCS): Handle new variable.
> > 	* gcc/mklibgcc.in: Handle LIB2_DIVMOD_ST_SH_FUNCS.
> > 	* gcc/mkmap-symver.awk: Handle symbols with @ specially.
> > 	* gcc/config/rs6000/t-ppccomm (TARGET_LIBGCC2_CFLAGS): Add
> >  	versioning header.
> > 	(LIB2_DIVMOD_ST_SH_FUNCS): Add symbols with multiple versions.
> > 	(SHLIB_MAPFILES): Use new version script.
> >  	* gcc/config/rs6000/divmod-symver.h: New file.
> >  	* gcc/config/rs6000/libgcc-glibc.ver: New file.
>
> I guess the patch is technically ok, but I still havn't
> seen a proper explanation of why this is needed at all.
> (If I've just missed it in the weekend's mail configuration
> debacle, I apologize.  Please point me at the url.)

Here's the subject index:

http://gcc.gnu.org/ml/gcc-patches/2002-08/subjects.html#00357

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Richard Henderson]

On Tue, Aug 06, 2002 at 09:23:58PM +0200, Franz Sirl wrote:
> 	* gcc/Makefile.in (LIB2_DIVMOD_ST_SH_FUNCS): Handle new variable.
> 	* gcc/mklibgcc.in: Handle LIB2_DIVMOD_ST_SH_FUNCS.
> 	* gcc/mkmap-symver.awk: Handle symbols with @ specially.
> 	* gcc/config/rs6000/t-ppccomm (TARGET_LIBGCC2_CFLAGS): Add
>  	versioning header.
> 	(LIB2_DIVMOD_ST_SH_FUNCS): Add symbols with multiple versions.
> 	(SHLIB_MAPFILES): Use new version script.
>  	* gcc/config/rs6000/divmod-symver.h: New file.
>  	* gcc/config/rs6000/libgcc-glibc.ver: New file.

I guess the patch is technically ok, but I still havn't
seen a proper explanation of why this is needed at all.
(If I've just missed it in the weekend's mail configuration
debacle, I apologize.  Please point me at the url.)


r~

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

On Montag, 5. August 2002 05:09, Mark Mitchell wrote:
> --On Sunday, August 04, 2002 09:02:02 PM +0200 Franz Sirl
>
> <Franz.Sirl-kernel@lauterbach.com> wrote:
> > Hi,
> >
> > this turned out to be more difficult than I thought, but finally I had
> > the  right idea on how to tackle that.
>
> I'm going to delegate this to Jakub/Richard.  They have more expertise.
>
> I do need to know by tomorrow whether this is going in or not; I want
> to spin the prerelease tomorrow night.

In order to inrease the acceptability of the patch, I reworked it towards 
minimum invasiveness.

OK to commit to 3.2 branch?

Franz.

2002-08-06  Franz Sirl  <Franz.Sirl-kernel@lauterbach.com>
                       Jakub Jelinek  <jakub@redhat.com>

	* gcc/Makefile.in (LIB2_DIVMOD_ST_SH_FUNCS): Handle new variable.
	* gcc/mklibgcc.in: Handle LIB2_DIVMOD_ST_SH_FUNCS.
	* gcc/mkmap-symver.awk: Handle symbols with @ specially.
	* gcc/config/rs6000/t-ppccomm (TARGET_LIBGCC2_CFLAGS): Add
 	versioning header.
	(LIB2_DIVMOD_ST_SH_FUNCS): Add symbols with multiple versions.
	(SHLIB_MAPFILES): Use new version script.
 	* gcc/config/rs6000/divmod-symver.h: New file.
 	* gcc/config/rs6000/libgcc-glibc.ver: New file.

[-- Attachment #2: gcc-libgcc-compat-ppc-2.patch --]
[-- Type: text/plain, Size: 7950 bytes --]

Index: gcc/Makefile.in
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.830.2.15
diff -u -p -r1.830.2.15 Makefile.in
--- gcc/Makefile.in	23 May 2002 17:57:21 -0000	1.830.2.15
+++ gcc/Makefile.in	6 Aug 2002 18:52:28 -0000
@@ -991,6 +991,7 @@ libgcc.mk: config.status Makefile mklibg
 	FPBIT='$(FPBIT)' \
 	FPBIT_FUNCS='$(FPBIT_FUNCS)' \
 	LIB2_DIVMOD_FUNCS='$(LIB2_DIVMOD_FUNCS)' \
+	LIB2_DIVMOD_ST_SH_FUNCS='$(LIB2_DIVMOD_ST_SH_FUNCS)' \
 	DPBIT='$(DPBIT)' \
 	DPBIT_FUNCS='$(DPBIT_FUNCS)' \
 	MULTILIBS=`$(GCC_FOR_TARGET) --print-multi-lib` \
Index: gcc/mklibgcc.in
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/mklibgcc.in,v
retrieving revision 1.37.4.9
diff -u -p -r1.37.4.9 mklibgcc.in
--- gcc/mklibgcc.in	9 May 2002 17:35:21 -0000	1.37.4.9
+++ gcc/mklibgcc.in	6 Aug 2002 18:52:28 -0000
@@ -19,6 +19,7 @@
 # FPBIT
 # FPBIT_FUNCS
 # LIB2_DIVMOD_FUNCS
+# LIB2_DIVMOD_ST_SH_FUNCS
 # DPBIT
 # DPBIT_FUNCS
 # LIBGCC
@@ -50,6 +51,7 @@ fi
 # Build lines.
 
 gcc_compile='$(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) $(INCLUDES)'
+gcc_compile_sh='$(GCC_FOR_TARGET) -DSHARED $(LIBGCC2_CFLAGS) $(LIBGCC2_SH_CFLAGS) $(INCLUDES)'
 make_compile='$(MAKE) GCC_FOR_TARGET="$(GCC_FOR_TARGET)" \
 	  AR_FOR_TARGET="$(AR_FOR_TARGET)" \
 	  AR_CREATE_FOR_TARGET="$(AR_CREATE_FOR_TARGET)" \
@@ -102,6 +104,7 @@ done
 #
 
 libgcc2_objs=""
+libgcc2_sh_objs=""
 libgcc2_st_objs=""
 libgcc2_eh_objs=""
 
@@ -131,6 +134,28 @@ for name in $LIB2FUNCS_ST; do
   libgcc2_st_objs="$libgcc2_st_objs ${name}${objext}"
 done
 
+for name in $LIB2_DIVMOD_ST_SH_FUNCS; do
+  for ml in $MULTILIBS; do
+    dir=`echo ${ml} | sed -e 's/;.*$//' -e 's/=/$(EQ)/g'`
+    flags=`echo ${ml} | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`;
+    out="libgcc/${dir}/${name}${objext}"
+
+    echo $out: $libgcc2_c_dep
+    echo "	$gcc_compile" '$(MAYBE_USE_COLLECT2)' $flags -DL$name \
+      -c '$(srcdir)/libgcc2.c' -fexceptions -fnon-call-exceptions -o $out
+
+    out="libgcc/${dir}/${name}${objext}s"
+    echo $out: $libgcc2_c_dep
+    echo "	$gcc_compile_sh" '$(MAYBE_USE_COLLECT2)' $flags -DL$name \
+      -c '$(srcdir)/libgcc2.c' -fexceptions -fnon-call-exceptions -o $out
+  done
+  libgcc2_st_objs="$libgcc2_st_objs ${name}${objext}"
+  libgcc2_sh_objs="$libgcc2_sh_objs ${name}${objext}s"
+  LIB2_DIVMOD_FUNCS=`echo $LIB2_DIVMOD_FUNCS | sed -e 's/^'$name' //' \
+				                     -e 's/ '$name' / /' \
+				                     -e 's/ '$name'$//'`
+done
+
 for name in $LIB2_DIVMOD_FUNCS; do
   for ml in $MULTILIBS; do
     dir=`echo ${ml} | sed -e 's/;.*$//' -e 's/=/$(EQ)/g'`
@@ -251,6 +276,9 @@ for ml in $MULTILIBS; do
     libgcc_eh_objs="$libgcc_eh_objs libgcc/${dir}/$o"
   done
   libgcc_sh_objs="$libgcc_objs $libgcc_eh_objs"
+  for o in $libgcc2_sh_objs; do
+    libgcc_sh_objs="$libgcc_sh_objs libgcc/${dir}/$o"
+  done
   shlib_deps="$libgcc_sh_objs"
 
   libgcc_st_objs=""
Index: gcc/mkmap-symver.awk
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/mkmap-symver.awk,v
retrieving revision 1.2.14.1
diff -u -p -r1.2.14.1 mkmap-symver.awk
--- gcc/mkmap-symver.awk	22 Mar 2002 00:57:15 -0000	1.2.14.1
+++ gcc/mkmap-symver.awk	6 Aug 2002 18:52:28 -0000
@@ -54,6 +54,9 @@ state == "nm" {
 # for beginning and ending each section, and %inherit markers for
 # describing version inheritence.  A symbol may appear in more than
 # one symbol version, and the last seen takes effect.
+# If symbol needs to appear in more than one symbol version,
+# it can be written as symbol@SYMBOL_VER, again only the last
+# such symbol@SYMBOL_VER pair takes effect.
 
 NF == 3 && $1 == "%inherit" {
   inherit[$2] = $3;
@@ -90,13 +93,17 @@ function output(lib) {
 
   printf("%s {\n", lib);
   printf("  global:\n");
-  for (sym in ver)
-    if ((ver[sym] == lib) && (sym in def))
-      {
-	printf("\t%s;\n", sym);
-	if (dotsyms)
-	  printf("\t.%s;\n", sym);
-      }
+  for (fullsym in ver)
+    {
+      sym=fullsym;
+      sub(/@.*$/,"",sym);
+      if ((ver[fullsym] == lib) && (fullsym in def))
+        {
+	  printf("\t%s;\n", sym);
+	  if (dotsyms)
+	    printf("\t.%s;\n", sym);
+        }
+    }
 
   if (inherit[lib])
     printf("} %s;\n", inherit[lib]);
Index: gcc/config/rs6000/t-ppccomm
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/rs6000/t-ppccomm,v
retrieving revision 1.15
diff -u -p -r1.15 t-ppccomm
--- gcc/config/rs6000/t-ppccomm	19 Feb 2002 19:40:41 -0000	1.15
+++ gcc/config/rs6000/t-ppccomm	6 Aug 2002 18:52:28 -0000
@@ -1,9 +1,18 @@
 # Common support for PowerPC ELF targets (both EABI and SVR4).
 
+TARGET_LIBGCC2_CFLAGS += -include $(srcdir)/config/rs6000/divmod-symver.h
+
 LIB2FUNCS_EXTRA = tramp.S
 
 # This one can't end up in shared libgcc
 LIB2FUNCS_STATIC_EXTRA = eabi.S
+
+# We need special versioning on these in shared objects
+LIB2_DIVMOD_ST_SH_FUNCS = _divdi3 _moddi3 _udivdi3 _umoddi3
+
+# Override t-slibgcc-elf-ver to export some libgcc symbols with
+# the symbol versions that glibc used.
+SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver $(srcdir)/config/rs6000/libgcc-glibc.ver
 
 # We want fine grained libraries, so use the new code to build the
 # floating point emulation libraries.
--- /dev/null	Thu Oct  4 06:30:44 2001
+++ gcc/config/rs6000/divmod-symver.h	Tue Aug  6 00:08:11 2002
@@ -0,0 +1,46 @@
+/*
+   Copyright (C) 2002 Free Software Foundation, Inc.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+#ifdef SHARED
+#ifdef L_divdi3
+asm (".set __divdi3_oldver,__divdi3");
+asm (".globl __divdi3_oldver");
+asm (".symver __divdi3_oldver,__divdi3@GLIBC_2.0");
+asm (".symver __divdi3,__divdi3@@@GCC_3.0");
+#endif
+#ifdef L_udivdi3
+asm (".set __udivdi3_oldver,__udivdi3");
+asm (".globl __udivdi3_oldver");
+asm (".symver __udivdi3_oldver,__udivdi3@GLIBC_2.0");
+asm (".symver __udivdi3,__udivdi3@@@GCC_3.0");
+#endif
+#ifdef L_moddi3
+asm (".set __moddi3_oldver,__moddi3");
+asm (".globl __moddi3_oldver");
+asm (".symver __moddi3_oldver,__moddi3@GLIBC_2.0");
+asm (".symver __moddi3,__moddi3@@@GCC_3.0");
+#endif
+#ifdef L_umoddi3
+asm (".set __umoddi3_oldver,__umoddi3");
+asm (".globl __umoddi3_oldver");
+asm (".symver __umoddi3_oldver,__umoddi3@GLIBC_2.0");
+asm (".symver __umoddi3,__umoddi3@@@GCC_3.0");
+#endif
+#endif
--- /dev/null	Thu Oct  4 06:30:44 2001
+++ gcc/config/rs6000/libgcc-glibc.ver	Sun Aug  4 03:43:40 2002
@@ -0,0 +1,24 @@
+# In order to work around the very problems that force us to now generally
+# create a libgcc.so, glibc reexported a number of routines from libgcc.a.
+# By now choosing the same version tags for these specific routines, we
+# maintain enough binary compatibility to allow future versions of glibc
+# to defer implementation of these routines to libgcc.so via DT_AUXILIARY.
+
+%inherit GCC_3.0 GLIBC_2.0
+
+GLIBC_2.0 {
+  # Sampling of DImode arithmetic
+  __divdi3@GLIBC_2.0
+  __udivdi3@GLIBC_2.0
+  __moddi3@GLIBC_2.0
+  __umoddi3@GLIBC_2.0
+
+  # Exception handling support functions used by most everyone.
+  __register_frame
+  __register_frame_table
+  __deregister_frame
+  __register_frame_info
+  __deregister_frame_info
+  __frame_state_for
+  __register_frame_info_table
+}

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Montag, 5. August 2002 21:08, Jakub Jelinek wrote:
> On Mon, Aug 05, 2002 at 08:42:35PM +0200, Franz Sirl wrote:
> > You would be right in an ideal world, but I've already seen this in the
> > wild, mostly with with really complex apps like OpenOffice depending on
> > other complex apps like mozilla. The problem is that glibc also exports
> > these 4 symbols with link-time reference (fixing that will be a follow-up
> > patch) and
>
> IMHO its just PPC which should not export it, IA-32 and others
> always exported this and it is not causing problems there.

IMO it should have been never exported as a versioned link-time reference from 
glibc on any platform, it simply isn't necessary.

> > there are still a bunch of apps that manually link shared libs with -lc
> > -lgcc (like openssl, KDE, mozilla, etcetc) instead of -lgcc -lc -lgcc or
> > using gcc to link.
>
> Apps using ld -shared instead of gcc -shared and g++ -shared need to
> be fixed, not workarounds added so that they can stay being broken some
> more time.

Hehe, have a lot of fun fixing libtool then :-).

> > That caused an undefined reference for __divdi3@GLIBC_2.0 when
> > running on a gcc2 compiled glibc, even though libgcc_s.so was delivered
> > with the app.
> > Now you could argue "this only happens during the transition", but
> > history shows us that things like that will bite us again and again :-).
>
> I still think it is enough just to change glibc.

I don't have enough support power to rely on "I think" :-). Unlike you come up 
with a really convincing argument for not doing it, I would like to fix that.

IMHO the initial bug was that gcc/config/libgcc-glibc.ver isn't generic as 
it's placement would suggest, but x86 specific and should have been placed in 
gcc/config/i386/. gcc/config/libgcc-glibc.ver shouldn't have included the 
divmod symbols.
But the deed is done and if gcc-3.0 and gcc-3.1 binaries wouldn't be that 
widely deployed on PPC I would even go as far as creating a 
gcc/config/rs6000/libgcc-glibc.ver without the divmod symbols, but I'm 
reluctant to do that as long as there is no glibc release (2.2.6/2.3) with 
the ppc versioning changes that would fulfill the symbol versions then 
missing from libgcc_s.

Hmm, but I would rather have that change than no change at all, even if that 
would require people to upgrade to an unreleased glibc. Hmm, maybe the full 
compat patch for 3.2 and only a fixed gcc/config/rs6000/libgcc-glibc.ver for 
3.3? Such a transition period would be acceptable to me.

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Jakub Jelinek]

On Mon, Aug 05, 2002 at 08:42:35PM +0200, Franz Sirl wrote:
> You would be right in an ideal world, but I've already seen this in the wild, 
> mostly with with really complex apps like OpenOffice depending on other 
> complex apps like mozilla. The problem is that glibc also exports these 4 
> symbols with link-time reference (fixing that will be a follow-up patch) and 

IMHO its just PPC which should not export it, IA-32 and others
always exported this and it is not causing problems there.

> there are still a bunch of apps that manually link shared libs with -lc -lgcc 
> (like openssl, KDE, mozilla, etcetc) instead of -lgcc -lc -lgcc or using gcc 
> to link.

Apps using ld -shared instead of gcc -shared and g++ -shared need to
be fixed, not workarounds added so that they can stay being broken some
more time.

> That caused an undefined reference for __divdi3@GLIBC_2.0 when 
> running on a gcc2 compiled glibc, even though libgcc_s.so was delivered with 
> the app.
> Now you could argue "this only happens during the transition", but history 
> shows us that things like that will bite us again and again :-).

I still think it is enough just to change glibc.

	Jakub

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

On Montag, 5. August 2002 18:27, Jakub Jelinek wrote:
> On Sun, Aug 04, 2002 at 09:02:02PM +0200, Franz Sirl wrote:
> > Hi,
> >
> > this turned out to be more difficult than I thought, but finally I had
> > the right idea on how to tackle that.
> >
> > The patch changes the symbol versions in the shared libgcc for these
> > sysmbols:
> >
> > 	__divdi3
> > 	__udivdi3
> > 	__moddi3
> > 	__umoddi3
> >
> > The change is to move the link-time reference from GLIBC_2.0 to GCC_3.0:
> >
> > 	3.0, 3.1:		run+linktime @@GLIBC_2.0, runtime @GCC_3.0
> > 	3.2+:		run+linktime @@GCC_3.0, runtime @GLIBC_2.0
>
> First of all, can you explain why that is needed?
> As glibc on PPC AFAIK was never exporting these symbols, they were added
> there just to cope with binaries/libraries taking those symbols from
> various shared libraries unintentionally exporting them. But all those
> were unversioned references, ie. it really doesn't matter what
> symbol version is glibc using for them.
> Newly built libraries/programs will either link against libgcc_s, in which
> case they will whatever symbol version libgcc_s exports (and
> it doesn't matter if it is different from glibc's version, since they have
> either direct or indirect DT_NEEDED on libgcc_s), or they'll use the
> .hidden routine from libgcc.a.

You would be right in an ideal world, but I've already seen this in the wild, 
mostly with with really complex apps like OpenOffice depending on other 
complex apps like mozilla. The problem is that glibc also exports these 4 
symbols with link-time reference (fixing that will be a follow-up patch) and 
there are still a bunch of apps that manually link shared libs with -lc -lgcc 
(like openssl, KDE, mozilla, etcetc) instead of -lgcc -lc -lgcc or using gcc 
to link. That caused an undefined reference for __divdi3@GLIBC_2.0 when 
running on a gcc2 compiled glibc, even though libgcc_s.so was delivered with 
the app.
Now you could argue "this only happens during the transition", but history 
shows us that things like that will bite us again and again :-). So I would 
really really like to fix even the remote possibility of problems in that 
area once and forever.

> Yes, some months ago I thought it would be a good idea to use the same
> symbol version, but IA-64 in the final version uses different versions and
> it doesn't cause any problems. Why is PPC any different here?

PPC has a lot more users and a longer history than IA64, triggering more 
compatibility problems.

Franz.

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Jakub Jelinek]

On Sun, Aug 04, 2002 at 09:02:02PM +0200, Franz Sirl wrote:
> Hi,
> 
> this turned out to be more difficult than I thought, but finally I had the 
> right idea on how to tackle that.
> 
> The patch changes the symbol versions in the shared libgcc for these sysmbols:
> 
> 	__divdi3	
> 	__udivdi3
> 	__moddi3
> 	__umoddi3
> 
> The change is to move the link-time reference from GLIBC_2.0 to GCC_3.0:
> 
> 	3.0, 3.1:		run+linktime @@GLIBC_2.0, runtime @GCC_3.0
> 	3.2+:		run+linktime @@GCC_3.0, runtime @GLIBC_2.0

First of all, can you explain why that is needed?
As glibc on PPC AFAIK was never exporting these symbols, they were added there
just to cope with binaries/libraries taking those symbols from various
shared libraries unintentionally exporting them. But all those
were unversioned references, ie. it really doesn't matter what
symbol version is glibc using for them.
Newly built libraries/programs will either link against libgcc_s, in which
case they will whatever symbol version libgcc_s exports (and
it doesn't matter if it is different from glibc's version, since they have
either direct or indirect DT_NEEDED on libgcc_s), or they'll use the .hidden
routine from libgcc.a.

Yes, some months ago I thought it would be a good idea to use the same
symbol version, but IA-64 in the final version uses different versions and
it doesn't cause any problems. Why is PPC any different here?

	Jakub

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Mark Mitchell]

--On Sunday, August 04, 2002 09:02:02 PM +0200 Franz Sirl 
<Franz.Sirl-kernel@lauterbach.com> wrote:

> Hi,
>
> this turned out to be more difficult than I thought, but finally I had
> the  right idea on how to tackle that.

I'm going to delegate this to Jakub/Richard.  They have more expertise.

I do need to know by tomorrow whether this is going in or not; I want
to spin the prerelease tomorrow night.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Daniel Jacobowitz]

On Sun, Aug 04, 2002 at 09:02:02PM +0200, Franz Sirl wrote:
> Hi,
> 
> this turned out to be more difficult than I thought, but finally I had the 
> right idea on how to tackle that.
> 
> The patch changes the symbol versions in the shared libgcc for these sysmbols:
> 
> 	__divdi3	
> 	__udivdi3
> 	__moddi3
> 	__umoddi3
> 
> The change is to move the link-time reference from GLIBC_2.0 to GCC_3.0:
> 
> 	3.0, 3.1:		run+linktime @@GLIBC_2.0, runtime @GCC_3.0
> 	3.2+:		run+linktime @@GCC_3.0, runtime @GLIBC_2.0
> 
> This is to finally break the interaction between gcc and glibc on these 
> symbols.
> 
> Bootstrapped on i686-linux-gnu and powerpc-linux-gnu without regressions.
> 
> I will do a few more compatibility checks today+tomorrow, OK to commit to 
> mainline and 3.2 branch after that?
> 
> BTW, I noticed that the symbols in libgcc.a are only hidden by mklibgcc if 
> SHLIB_LINK is set, is this intentional? Doesn't that mean you have to build 
> gcc and glibc 2 times in a cross-compile environment to get a correct glibc 
> with no re-exported libgcc symbols?

I've been using this:

  Fix a visibility problem on libgcc, which led to PowerPC glibc build
  failures.  I need to take this up with the GCC developers at next
  opportunity; it may not be correct for all platforms (but is for all
  of our platforms).
    - djacobowitz

--- gcc-3.1/gcc/mklibgcc.in.orig	Wed Jul 24 12:23:59 2002
+++ gcc-3.1/gcc/mklibgcc.in	Wed Jul 24 12:24:26 2002
@@ -279,7 +279,7 @@
 
   libgcc_a_objs="$libgcc_objs $libgcc_st_objs"
 
-  if [ "@libgcc_visibility@" = yes -a "$SHLIB_LINK" ]; then
+  if [ "@libgcc_visibility@" = yes ]; then
     libgcc_a_objs=
     echo ""
     for o in $libgcc_objs $libgcc_st_objs; do


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

[PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Franz Sirl]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

Hi,

this turned out to be more difficult than I thought, but finally I had the 
right idea on how to tackle that.

The patch changes the symbol versions in the shared libgcc for these sysmbols:

	__divdi3	
	__udivdi3
	__moddi3
	__umoddi3

The change is to move the link-time reference from GLIBC_2.0 to GCC_3.0:

	3.0, 3.1:		run+linktime @@GLIBC_2.0, runtime @GCC_3.0
	3.2+:		run+linktime @@GCC_3.0, runtime @GLIBC_2.0

This is to finally break the interaction between gcc and glibc on these 
symbols.

Bootstrapped on i686-linux-gnu and powerpc-linux-gnu without regressions.

I will do a few more compatibility checks today+tomorrow, OK to commit to 
mainline and 3.2 branch after that?

BTW, I noticed that the symbols in libgcc.a are only hidden by mklibgcc if 
SHLIB_LINK is set, is this intentional? Doesn't that mean you have to build 
gcc and glibc 2 times in a cross-compile environment to get a correct glibc 
with no re-exported libgcc symbols?

Jakub, do you want to use this framework for any other platform in 3.2?

Franz.

2002-08-04  Franz Sirl  <Franz.Sirl-kernel@lauterbach.com>
	               Jakub Jelinek  <jakub@redhat.com>

	* gcc/Makefile.in (LIBGCC2_SH_CFLAGS, TARGET_LIBGCC2_SH_CFLAGS,
	LIB2ADD_SH, LIB2_DIVMOD_ST_SH_FUNCS): Handle new variables.
	* gcc/mklibgcc.in: Handle LIB2ADD and LIB2_DIVMOD_ST_SH_FUNCS.
	* gcc/mkmap-symver.awk: Handle symbols with @ specially.
	* gcc/config/rs6000/t-ppccomm (TARGET_LIBGCC2_SH_CFLAGS): Include
	versioning header.
	(LIB2FUNCS_SHARED_EXTRA): Set to file with older versions function stubs.
	(LIB2_DIVMOD_ST_SH_FUNCS): Add symbols with multiple versions.
	(SHLIB_MAPFILES): Use new version script.
	* gcc/config/rs6000/divmod-symver.h: New file.
	* gcc/config/rs6000/divmod-ver.asm: New file.
	* gcc/config/rs6000/libgcc-glibc.ver: New file.



[-- Attachment #2: gcc-libgcc-compat-ppc-1.patch --]
[-- Type: text/plain, Size: 15041 bytes --]

Index: gcc/Makefile.in
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.830.2.15
diff -u -p -r1.830.2.15 Makefile.in
--- gcc/Makefile.in	23 May 2002 17:57:21 -0000	1.830.2.15
+++ gcc/Makefile.in	4 Aug 2002 10:59:01 -0000
@@ -359,6 +359,7 @@ INSTALL_LIBGCC = install-libgcc
 #
 LIBGCC2_DEBUG_CFLAGS = -g
 LIBGCC2_CFLAGS = -O2 $(LIBGCC2_INCLUDES) $(GCC_CFLAGS) $(TARGET_LIBGCC2_CFLAGS) $(LIBGCC2_DEBUG_CFLAGS) $(GTHREAD_FLAGS) -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED @inhibit_libc@
+LIBGCC2_SH_CFLAGS = $(TARGET_LIBGCC2_SH_CFLAGS)
 
 # Additional options to use when compiling libgcc2.a.
 # Some targets override this to -isystem include
@@ -367,6 +368,9 @@ LIBGCC2_INCLUDES =
 # Additional target-dependent options for compiling libgcc2.a.
 TARGET_LIBGCC2_CFLAGS =
 
+# Additional target-dependent options for compiling objects for libgcc2.so.
+TARGET_LIBGCC2_SH_CFLAGS =
+
 # Options to use when compiling crtbegin/end.
 CRTSTUFF_CFLAGS = -O2 $(GCC_CFLAGS) $(INCLUDES) $(MULTILIB_CFLAGS) -g0 \
   -finhibit-size-directive -fno-inline-functions -fno-exceptions
@@ -976,21 +980,24 @@ xlimits.h: glimits.h limitx.h limity.h
 # Build libgcc.a.
 
 LIB2ADD = $(LIB2FUNCS_EXTRA)
+LIB2ADD_SH = $(LIB2FUNCS_SHARED_EXTRA)
 LIB2ADD_ST = $(LIB2FUNCS_STATIC_EXTRA)
 
-libgcc.mk: config.status Makefile mklibgcc $(LIB2ADD) $(LIB2ADD_ST) xgcc$(exeext)
+libgcc.mk: config.status Makefile mklibgcc $(LIB2ADD) $(LIB2ADD_SH) $(LIB2ADD_ST) xgcc$(exeext)
 	objext='$(objext)' \
 	LIB1ASMFUNCS='$(LIB1ASMFUNCS)' \
 	LIB2FUNCS_1='$(LIB2FUNCS_1)' \
 	LIB2FUNCS_2='$(LIB2FUNCS_2)' \
 	LIB2FUNCS_ST='$(LIB2FUNCS_ST)' \
 	LIB2ADD='$(LIB2ADD)' \
+	LIB2ADD_SH='$(LIB2ADD_SH)' \
 	LIB2ADD_ST='$(LIB2ADD_ST)' \
 	LIB2ADDEH='$(LIB2ADDEH)' \
 	LIB2ADDEHDEP='$(LIB2ADDEHDEP)' \
 	FPBIT='$(FPBIT)' \
 	FPBIT_FUNCS='$(FPBIT_FUNCS)' \
 	LIB2_DIVMOD_FUNCS='$(LIB2_DIVMOD_FUNCS)' \
+	LIB2_DIVMOD_ST_SH_FUNCS='$(LIB2_DIVMOD_ST_SH_FUNCS)' \
 	DPBIT='$(DPBIT)' \
 	DPBIT_FUNCS='$(DPBIT_FUNCS)' \
 	MULTILIBS=`$(GCC_FOR_TARGET) --print-multi-lib` \
@@ -1012,8 +1019,9 @@ libgcc.mk: config.status Makefile mklibg
 LIBGCC_DEPS = $(GCC_PASSES) $(LANGUAGES) stmp-int-hdrs $(STMP_FIXPROTO) \
 	libgcc.mk $(srcdir)/libgcc2.c $(TCONFIG_H) \
 	$(MACHMODE_H) longlong.h gbl-ctors.h config.status stmp-int-hdrs \
-	tsystem.h $(FPBIT) $(DPBIT) $(LIB2ADD) $(LIB2ADD_ST) $(LIB2ADDEH) \
-	$(LIB2ADDEHDEP) $(EXTRA_PARTS) $(srcdir)/config/$(LIB1ASMSRC)
+	tsystem.h $(FPBIT) $(DPBIT) $(LIB2ADD) $(LIB2ADD_SH) $(LIB2ADD_ST) \
+	$(LIB2ADDEH) $(LIB2ADDEHDEP) $(EXTRA_PARTS) \
+	$(srcdir)/config/$(LIB1ASMSRC)
 
 libgcc.a: $(LIBGCC_DEPS)
 	$(MAKE) GCC_FOR_TARGET="$(GCC_FOR_TARGET)" \
@@ -1026,6 +1034,7 @@ libgcc.a: $(LIBGCC_DEPS)
 	  RANLIB_TEST_FOR_TARGET="$(RANLIB_TEST_FOR_TARGET)" \
 	  NM_FOR_TARGET="$(NM_FOR_TARGET)" AWK="$(AWK)" \
 	  LIBGCC2_CFLAGS="$(LIBGCC2_CFLAGS)" \
+	  LIBGCC2_SH_CFLAGS="$(LIBGCC2_SH_CFLAGS)" \
 	  INCLUDES="$(INCLUDES)" \
 	  CONFIG_H="$(TCONFIG_H)" MACHMODE_H="$(MACHMODE_H)" \
 	  LIB1ASMSRC='$(LIB1ASMSRC)' \
@@ -1064,6 +1073,7 @@ stmp-multilib: $(LIBGCC_DEPS)
 	  RANLIB_TEST_FOR_TARGET="$(RANLIB_TEST_FOR_TARGET)" \
 	  NM_FOR_TARGET="$(NM_FOR_TARGET)" AWK="$(AWK)" \
 	  LIBGCC2_CFLAGS="$(LIBGCC2_CFLAGS)" \
+	  LIBGCC2_SH_CFLAGS="$(LIBGCC2_SH_CFLAGS)" \
 	  INCLUDES="$(INCLUDES)" \
 	  CONFIG_H="$(CONFIG_H)" MACHMODE_H="$(MACHMODE_H)" \
 	  LIB1ASMSRC='$(LIB1ASMSRC)' \
@@ -2723,6 +2726,7 @@ install-libgcc: libgcc.mk libgcc.a insta
 	  RANLIB_TEST_FOR_TARGET="$(RANLIB_TEST_FOR_TARGET)" \
 	  NM_FOR_TARGET="$(NM_FOR_TARGET)" AWK="$(AWK)" \
 	  LIBGCC2_CFLAGS="$(LIBGCC2_CFLAGS)" \
+	  LIBGCC2_SH_CFLAGS="$(LIBGCC2_SH_CFLAGS)" \
 	  INCLUDES="$(INCLUDES)" \
 	  CONFIG_H="$(TCONFIG_H)" MACHMODE_H="$(MACHMODE_H)" \
 	  LIB1ASMSRC='$(LIB1ASMSRC)' \
@@ -2749,6 +2753,7 @@ install-multilib: stmp-multilib installd
 	  RANLIB_TEST_FOR_TARGET="$(RANLIB_TEST_FOR_TARGET)" \
 	  NM_FOR_TARGET="$(NM_FOR_TARGET)" AWK="$(AWK)" \
 	  LIBGCC2_CFLAGS="$(LIBGCC2_CFLAGS)" \
+	  LIBGCC2_SH_CFLAGS="$(LIBGCC2_SH_CFLAGS)" \
 	  INCLUDES="$(INCLUDES)" \
 	  CONFIG_H="$(CONFIG_H)" MACHMODE_H="$(MACHMODE_H)" \
 	  LIB1ASMSRC='$(LIB1ASMSRC)' \
Index: gcc/mklibgcc.in
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/mklibgcc.in,v
retrieving revision 1.37.4.9
diff -u -p -r1.37.4.9 mklibgcc.in
--- gcc/mklibgcc.in	9 May 2002 17:35:21 -0000	1.37.4.9
+++ gcc/mklibgcc.in	4 Aug 2002 10:59:01 -0000
@@ -13,12 +13,14 @@
 # LIB2FUNCS_2
 # LIB2FUNCS_ST
 # LIB2ADD
+# LIB2ADD_SH
 # LIB2ADD_ST 
 # LIB2ADDEH
 # LIB2ADDEHDEP
 # FPBIT
 # FPBIT_FUNCS
 # LIB2_DIVMOD_FUNCS
+# LIB2_DIVMOD_ST_SH_FUNCS
 # DPBIT
 # DPBIT_FUNCS
 # LIBGCC
@@ -50,6 +52,7 @@ fi
 # Build lines.
 
 gcc_compile='$(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) $(INCLUDES)'
+gcc_compile_sh='$(GCC_FOR_TARGET) -DSHARED $(LIBGCC2_CFLAGS) $(LIBGCC2_SH_CFLAGS) $(INCLUDES)'
 make_compile='$(MAKE) GCC_FOR_TARGET="$(GCC_FOR_TARGET)" \
 	  AR_FOR_TARGET="$(AR_FOR_TARGET)" \
 	  AR_CREATE_FOR_TARGET="$(AR_CREATE_FOR_TARGET)" \
@@ -102,6 +105,7 @@ done
 #
 
 libgcc2_objs=""
+libgcc2_sh_objs=""
 libgcc2_st_objs=""
 libgcc2_eh_objs=""
 
@@ -131,6 +135,28 @@ for name in $LIB2FUNCS_ST; do
   libgcc2_st_objs="$libgcc2_st_objs ${name}${objext}"
 done
 
+for name in $LIB2_DIVMOD_ST_SH_FUNCS; do
+  for ml in $MULTILIBS; do
+    dir=`echo ${ml} | sed -e 's/;.*$//' -e 's/=/$(EQ)/g'`
+    flags=`echo ${ml} | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`;
+    out="libgcc/${dir}/${name}${objext}"
+
+    echo $out: $libgcc2_c_dep
+    echo "	$gcc_compile" '$(MAYBE_USE_COLLECT2)' $flags -DL$name \
+      -c '$(srcdir)/libgcc2.c' -fexceptions -fnon-call-exceptions -o $out
+
+    out="libgcc/${dir}/${name}${objext}s"
+    echo $out: $libgcc2_c_dep
+    echo "	$gcc_compile_sh" '$(MAYBE_USE_COLLECT2)' $flags -DL$name \
+      -c '$(srcdir)/libgcc2.c' -fexceptions -fnon-call-exceptions -o $out
+  done
+  libgcc2_st_objs="$libgcc2_st_objs ${name}${objext}"
+  libgcc2_sh_objs="$libgcc2_sh_objs ${name}${objext}s"
+  LIB2_DIVMOD_FUNCS=`echo $LIB2_DIVMOD_FUNCS | sed -e 's/^'$name' //' \
+				                     -e 's/ '$name' / /' \
+				                     -e 's/ '$name'$//'`
+done
+
 for name in $LIB2_DIVMOD_FUNCS; do
   for ml in $MULTILIBS; do
     dir=`echo ${ml} | sed -e 's/;.*$//' -e 's/=/$(EQ)/g'`
@@ -232,6 +258,24 @@ for file in $LIB2ADD_ST; do
   libgcc2_st_objs="$libgcc2_st_objs ${oname}${objext}"
 done
 
+for file in $LIB2ADD_SH; do
+  name=`echo $file | sed -e 's/[.][cSo]$//' -e 's/[.]asm$//' -e 's/[.]txt$//'`
+  oname=`echo $name | sed -e 's,.*/,,'`
+
+  for ml in $MULTILIBS; do
+    dir=`echo ${ml} | sed -e 's/;.*$//' -e 's/=/$(EQ)/g'`
+    flags=`echo ${ml} | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`;
+    out="libgcc/${dir}/${oname}${objext}s"
+    if [ ${name}.asm = ${file} ]; then
+      flags="$flags -xassembler-with-cpp"
+    fi
+
+    echo $out: stmp-dirs $file
+    echo "	$gcc_compile_sh" $flags -c $file -o $out
+  done
+  libgcc2_sh_objs="$libgcc2_sh_objs ${oname}${objext}s"
+done
+
 # SHLIB_MKMAP
 # SHLIB_MKMAP_OPTS
 # SHLIB_MAPFILES
@@ -251,6 +295,9 @@ for ml in $MULTILIBS; do
     libgcc_eh_objs="$libgcc_eh_objs libgcc/${dir}/$o"
   done
   libgcc_sh_objs="$libgcc_objs $libgcc_eh_objs"
+  for o in $libgcc2_sh_objs; do
+    libgcc_sh_objs="$libgcc_sh_objs libgcc/${dir}/$o"
+  done
   shlib_deps="$libgcc_sh_objs"
 
   libgcc_st_objs=""
Index: gcc/mkmap-symver.awk
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/mkmap-symver.awk,v
retrieving revision 1.2.14.1
diff -u -p -r1.2.14.1 mkmap-symver.awk
--- gcc/mkmap-symver.awk	22 Mar 2002 00:57:15 -0000	1.2.14.1
+++ gcc/mkmap-symver.awk	4 Aug 2002 10:59:01 -0000
@@ -54,6 +54,9 @@ state == "nm" {
 # for beginning and ending each section, and %inherit markers for
 # describing version inheritence.  A symbol may appear in more than
 # one symbol version, and the last seen takes effect.
+# If symbol needs to appear in more than one symbol version,
+# it can be written as symbol@SYMBOL_VER, again only the last
+# such symbol@SYMBOL_VER pair takes effect.
 
 NF == 3 && $1 == "%inherit" {
   inherit[$2] = $3;
@@ -90,13 +93,17 @@ function output(lib) {
 
   printf("%s {\n", lib);
   printf("  global:\n");
-  for (sym in ver)
-    if ((ver[sym] == lib) && (sym in def))
-      {
-	printf("\t%s;\n", sym);
-	if (dotsyms)
-	  printf("\t.%s;\n", sym);
-      }
+  for (fullsym in ver)
+    {
+      sym=fullsym;
+      sub(/@.*$/,"",sym);
+      if ((ver[fullsym] == lib) && (fullsym in def))
+        {
+	  printf("\t%s;\n", sym);
+	  if (dotsyms)
+	    printf("\t.%s;\n", sym);
+        }
+    }
 
   if (inherit[lib])
     printf("} %s;\n", inherit[lib]);
Index: gcc/config/rs6000/t-ppccomm
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/rs6000/t-ppccomm,v
retrieving revision 1.15
diff -u -p -r1.15 t-ppccomm
--- gcc/config/rs6000/t-ppccomm	19 Feb 2002 19:40:41 -0000	1.15
+++ gcc/config/rs6000/t-ppccomm	4 Aug 2002 10:59:01 -0000
@@ -1,10 +1,22 @@
 # Common support for PowerPC ELF targets (both EABI and SVR4).
 
+TARGET_LIBGCC2_SH_CFLAGS = -include $(srcdir)/config/rs6000/divmod-symver.h
+
 LIB2FUNCS_EXTRA = tramp.S
 
 # This one can't end up in shared libgcc
 LIB2FUNCS_STATIC_EXTRA = eabi.S
 
+# This one should only be in the shared libgcc
+LIB2FUNCS_SHARED_EXTRA = divmod-ver.S
+
+# We need special versioning on these in shared objects
+LIB2_DIVMOD_ST_SH_FUNCS = _divdi3 _moddi3 _udivdi3 _umoddi3
+
+# Override t-slibgcc-elf-ver to export some libgcc symbols with
+# the symbol versions that glibc used.
+SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver $(srcdir)/config/rs6000/libgcc-glibc.ver
+
 # We want fine grained libraries, so use the new code to build the
 # floating point emulation libraries.
 FPBIT = fp-bit.c
@@ -23,6 +35,9 @@ eabi.S: $(srcdir)/config/rs6000/eabi.asm
 
 tramp.S: $(srcdir)/config/rs6000/tramp.asm
 	cat $(srcdir)/config/rs6000/tramp.asm > tramp.S
+
+divmod-ver.S: $(srcdir)/config/rs6000/divmod-ver.asm
+	cat $(srcdir)/config/rs6000/divmod-ver.asm > divmod-ver.S
 
 # Switch synonyms
 MULTILIB_MATCHES_FLOAT	= msoft-float=mcpu?401 \
--- /dev/null	Thu Oct  4 06:30:44 2001
+++ gcc/config/rs6000/divmod-symver.h	Sun Aug  4 03:55:30 2002
@@ -0,0 +1,34 @@
+/*
+   Copyright (C) 2002 Free Software Foundation, Inc.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+#ifdef SHARED
+#ifdef L_divdi3
+asm (".symver __divdi3,__divdi3@@@GCC_3.0");
+#endif
+#ifdef L_udivdi3
+asm (".symver __udivdi3,__udivdi3@@@GCC_3.0");
+#endif
+#ifdef L_moddi3
+asm (".symver __moddi3,__moddi3@@@GCC_3.0");
+#endif
+#ifdef L_umoddi3
+asm (".symver __umoddi3,__umoddi3@@@GCC_3.0");
+#endif
+#endif
--- /dev/null	Thu Oct  4 06:30:44 2001
+++ gcc/config/rs6000/divmod-ver.asm	Sun Aug  4 03:53:26 2002
@@ -0,0 +1,71 @@
+/*
+ *   Copyright (C) 2002 Free Software Foundation, Inc.
+ *
+ * This file is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * In addition to the permissions in the GNU General Public License, the
+ * Free Software Foundation gives you unlimited permission to link the
+ * compiled version of this file with other programs, and to distribute
+ * those programs without any restriction coming from the use of this
+ * file.  (The General Public License restrictions do apply in other
+ * respects; for example, they cover modification of the file, and
+ * distribution when not linked into another program.)
+ *
+ * This file is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.  If not, write to
+ * the Free Software Foundation, 59 Temple Place - Suite 330,
+ * Boston, MA 02111-1307, USA.
+ *
+ *    As a special exception, if you link this library with files
+ *    compiled with GCC to produce an executable, this does not cause
+ *    the resulting executable to be covered by the GNU General Public License.
+ *    This exception does not however invalidate any other reasons why
+ *    the executable file might be covered by the GNU General Public License.
+ */
+
+	.file	"vers.asm"
+#ifdef SHARED
+	.section	".text"
+
+	.align	2
+	.globl __divdi3_v_glibc20
+	.type	__divdi3_v_glibc20,@function
+__divdi3_v_glibc20:
+	b	__divdi3@local
+.Lfe1:
+	.size	__divdi3_v_glibc20,.Lfe1-__divdi3_v_glibc20
+
+	.globl __udivdi3_v_glibc20
+	.type	__udivdi3_v_glibc20,@function
+__udivdi3_v_glibc20:
+	b	__udivdi3@local
+.Lfe2:
+	.size	__udivdi3_v_glibc20,.Lfe2-__udivdi3_v_glibc20
+
+	.globl __moddi3_v_glibc20
+	.type	__moddi3_v_glibc20,@function
+__moddi3_v_glibc20:
+	b	__moddi3@local
+.Lfe3:
+	.size	__moddi3_v_glibc20,.Lfe3-__moddi3_v_glibc20
+
+	.globl __umoddi3_v_glibc20
+	.type	__umoddi3_v_glibc20,@function
+__umoddi3_v_glibc20:
+	b	__umoddi3@local
+.Lfe4:
+	.size	__umoddi3_v_glibc20,.Lfe4-__umoddi3_v_glibc20
+
+	.symver	__divdi3_v_glibc20,__divdi3@GLIBC_2.0
+	.symver	__udivdi3_v_glibc20,__udivdi3@GLIBC_2.0
+	.symver	__moddi3_v_glibc20,__moddi3@GLIBC_2.0
+	.symver	__umoddi3_v_glibc20,__umoddi3@GLIBC_2.0
+#endif
--- /dev/null	Thu Oct  4 06:30:44 2001
+++ gcc/config/rs6000/libgcc-glibc.ver	Sun Aug  4 03:43:40 2002
@@ -0,0 +1,24 @@
+# In order to work around the very problems that force us to now generally
+# create a libgcc.so, glibc reexported a number of routines from libgcc.a.
+# By now choosing the same version tags for these specific routines, we
+# maintain enough binary compatibility to allow future versions of glibc
+# to defer implementation of these routines to libgcc.so via DT_AUXILIARY.
+
+%inherit GCC_3.0 GLIBC_2.0
+
+GLIBC_2.0 {
+  # Sampling of DImode arithmetic
+  __divdi3@GLIBC_2.0
+  __udivdi3@GLIBC_2.0
+  __moddi3@GLIBC_2.0
+  __umoddi3@GLIBC_2.0
+
+  # Exception handling support functions used by most everyone.
+  __register_frame
+  __register_frame_table
+  __deregister_frame
+  __register_frame_info
+  __deregister_frame_info
+  __frame_state_for
+  __register_frame_info_table
+}