printing exceptions?

printing exceptions?

[Tom Tromey]

I've noticed that recently, if `gij' tries to print an exception, it
prints the first line and then hangs.  Is anybody else seeing this?

strace shows something weird going on in the child process.  Instead
of exec'ing, it is trying to write to fd 6 (I haven't yet tracked down
what that is connected to).  Weird.

Tom

Re: printing exceptions?

[Andrew Pinski]

On Saturday, March 2, 2002, at 06:31 , Tom Tromey wrote:

> I've noticed that recently, if `gij' tries to print an exception, it
> prints the first line and then hangs.  Is anybody else seeing this?
>
> strace shows something weird going on in the child process.  Instead
> of exec'ing, it is trying to write to fd 6 (I haven't yet tracked down
> what that is connected to).  Weird.
>
> Tom


Yes, I see that with a complied to native code version.
It happens only once in a while but it does happen.

Thanks,
Andrew Pinski

Re: printing exceptions?

[Bryce McKinlay]

Tom Tromey wrote:

>I've noticed that recently, if `gij' tries to print an exception, it
>prints the first line and then hangs.  Is anybody else seeing this?
>

Yes. Actually, now that I look at it, EH isn't working at all with the 
interpreter on PowerPC. _Unwind_RaiseException() is returning 
_URC_NO_REASON and libgcj aborts. But thats another problem.

>strace shows something weird going on in the child process.  Instead
>of exec'ing, it is trying to write to fd 6 (I haven't yet tracked down
>what that is connected to).  Weird.
>

I see it hanging on the read() call at natPosixProcess.cc:278. Seems 
like Runtime.exec() always fails under the interpreter (works fine from 
compiled code). Weird indeed.

public class Test
{
  public static void main(String[] args) throws java.io.IOException
  {
    Process p = Runtime.getRuntime().exec("ls");
  }
}

regards

Bryce.

Re: printing exceptions?

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Bryce> I see it hanging on the read() call at
Bryce> natPosixProcess.cc:278. Seems like Runtime.exec() always fails
Bryce> under the interpreter (works fine from compiled code). Weird
Bryce> indeed.

Bryce> public class Test
Bryce> {
Bryce>   public static void main(String[] args) throws java.io.IOException
Bryce>   {
Bryce>     Process p = Runtime.getRuntime().exec("ls");
Bryce>   }
Bryce> }

I've spent an inordinate amount of time looking at this.  I've rebuilt
libgcj from scratch 5 or 6 times in the last couple days.

I think the bug occurs here:

    LIBLINK = $(LIBTOOL) --tag=CXX --mode=link $(CXX) -L$(here) $(JC1FLAGS) $(LDFLAGS) -o $@

If I change this to use `--tag=CC', then the bug goes away.
I have no theory to explain this.

Alexandre, do you have any insight here?
Is there any reason I shouldn't just make the above change and check
it in?  This represents a very serious (and weird) regression.

Tom

Re: printing exceptions?

[Bryce McKinlay]

Tom Tromey wrote:

>I've spent an inordinate amount of time looking at this.  I've rebuilt
>libgcj from scratch 5 or 6 times in the last couple days.
>
>I think the bug occurs here:
>
>    LIBLINK = $(LIBTOOL) --tag=CXX --mode=link $(CXX) -L$(here) $(JC1FLAGS) $(LDFLAGS) -o $@
>
>If I change this to use `--tag=CC', then the bug goes away.
>I have no theory to explain this.
>
>Alexandre, do you have any insight here?
>Is there any reason I shouldn't just make the above change and check
>it in?  This represents a very serious (and weird) regression.
>

Could it be link order? I noticed libtool was adding some "-lgcc_s" type 
stuff to the link lines for the binaries in libgcj. This messes up the 
link order, causing libgcc to be linked after some of the other shared libs.

regards

Bryce.

Re: printing exceptions?

[Alexandre Oliva]

On Mar  5, 2002, Tom Tromey <tromey@redhat.com> wrote:

>     LIBLINK = $(LIBTOOL) --tag=CXX --mode=link $(CXX) -L$(here) $(JC1FLAGS) $(LDFLAGS) -o $@

> If I change this to use `--tag=CC', then the bug goes away.
> I have no theory to explain this.

Do you have the link commands printed by libtool for both
alternatives?

-- 
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                Professional serial bug killer

Re: printing exceptions?

[Adam Megacz]

Tom Tromey <tromey@redhat.com> writes:
> I've rebuilt libgcj from scratch 5 or 6 times in the last couple
> days.

Misery loves company; I've probably rebuilt it from scratch upwards of
30 times since Thursday. Have I mentioned how much I hate the gcc EH
code?

You know you've done too many builds when you can detect libgcj.a
being populated by the pattern of noises coming from your hard drive.

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: printing exceptions?

[Tom Tromey]

>>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:

Adam> You know you've done too many builds when you can detect
Adam> libgcj.a being populated by the pattern of noises coming from
Adam> your hard drive.

Bryce's trick is to configure --disable-static.  This does half the
work.  I still haven't turned this on, out of inertia more than
anything else.

Tom

Re: printing exceptions?

[Adam Megacz]

Tom Tromey <tromey@redhat.com> writes:
> Bryce's trick is to configure --disable-static.

Yeah, I actually need libgcj.a since I can't do shared builds on Win32
(yet).

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: printing exceptions?

[Tom Tromey]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

Alexandre> Do you have the link commands printed by libtool for both
Alexandre> alternatives?

Each link line was about 50K by itself.
I can send them to you if you really want them.

Meanwhile I put each line into its own file and turned spaces into
newlines.  Then I diffed the files.  Here's the result:

--- Bug	Tue Mar  5 18:00:57 2002
+++ No-bug	Tue Mar  5 18:01:19 2002
@@ -1,24 +1,10 @@
 /x1/egcs/build/gcc/xgcc
--shared-libgcc
 -B/x1/egcs/build/gcc/
--nostdinc++
--nostdinc++
--I/x1/egcs/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
--I/x1/egcs/build/i686-pc-linux-gnu/libstdc++-v3/include
--I/x1/egcs/gcc/libstdc++-v3/libsupc++
--I/x1/egcs/gcc/libstdc++-v3/libio
--I/x1/egcs/gcc/libstdc++-v3/include/backward
--I/x1/egcs/gcc/libstdc++-v3/testsuite
--L/x1/egcs/build/i686-pc-linux-gnu/libstdc++-v3/src
--L/x1/egcs/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
 -B/x1/egcs/install/i686-pc-linux-gnu/bin/
 -B/x1/egcs/install/i686-pc-linux-gnu/lib/
 -isystem
 /x1/egcs/install/i686-pc-linux-gnu/include
 -shared
--nostdlib
-/usr/lib/crti.o
-/x1/egcs/build/gcc/crtbeginS.o
 
 .libs/prims.o
 .libs/jni.o
@@ -1284,18 +1270,10 @@
 -L/x1/egcs/build/i686-pc-linux-gnu/libjava/../boehm-gc/.libs
 ./../zlib/.libs/libzgcj.so
 -L/x1/egcs/build/i686-pc-linux-gnu/libjava/../zlib/.libs
--L/x1/egcs/build/gcc
--L/x1/egcs/install/lib/gcc-lib/i686-pc-linux-gnu/3.2
--L/x1/egcs/install/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../..
--lgcc_s
--lc
--lgcc_s
 
 
 
 
-/x1/egcs/build/gcc/crtendS.o
-/usr/lib/crtn.o
 
 -Wl,-soname
 -Wl,libgcj.so.2

Tom

Re: printing exceptions?

[Bryce McKinlay]

Tom Tromey wrote:

>>>>>>"Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
>>>>>>
>
>Alexandre> Do you have the link commands printed by libtool for both
>Alexandre> alternatives?
>
>Each link line was about 50K by itself.
>I can send them to you if you really want them.
>

I believe its the link command for the "gij" binary itself which is the 
problem, not the linking of libgcj.so.

If I compile gij myself like:

$ gcj gij.cc -I/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/ 
-I/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/include -I./include/

then it works fine.

The difference is that libtool passes an explicit "-lgcc_s -lc -lgcc_s" 
to gcj (or c++?) which changes the link order so that libgcc_s is not 
linked first.

ie working hand built gij:

$ ldd ./a.out
        libgcc_s.so.1 => /home/bryce/gcc/lib/libgcc_s.so.1 (0x40018000)
        libgcj.so.2 => /home/bryce/gcc/lib/libgcj.so.2 (0x40020000)
...

broken libtool built gij:

$ ldd `which gij`
        libgcj.so.2 => /home/bryce/gcc31/lib/libgcj.so.2 (0x40018000)
        libdl.so.2 => /lib/libdl.so.2 (0x4057c000)
        libgcjgc.so.1 => /home/bryce/gcc31/lib/libgcjgc.so.1 (0x40580000)
        libzgcj.so.0 => /home/bryce/gcc31/lib/libzgcj.so.0 (0x405ac000)
        libgcc_s.so.1 => /home/bryce/gcc31/lib/libgcc_s.so.1 
(0x405ba000)   <-----  !!!!
...

regards

Bryce.

Re: printing exceptions?

[Alexandre Oliva]

On Mar  5, 2002, Tom Tromey <tromey@redhat.com> wrote:

> Each link line was about 50K by itself.
> I can send them to you if you really want them.

Ok, I'll pass that.  Thanks for doing the grunt work of finding the
differences between the link commands that I had volunteered to do
myself :-)

> Meanwhile I put each line into its own file and turned spaces into
> newlines.  Then I diffed the files.  Here's the result:

The diffs look perfectly reasonable, except that they indicate you
haven't cleaned <target>/config.cache as recommended after the patch
that removed libstdc++-v3 flags from libjava's CXX went in.  But this
shouldn't matter.

The important difference here is that, if you use xgcc but not
-shared-libgcc, the libjava shared library won't be linked with the
shared version of libgcc.  It's my understanding that this *should* be
a problem.  I don't understand why what you're seeing is the exact
converse, namely, that by omitting -shared-libgcc, you get correct
a working program&shared library, but by leaving it in, things break.
Richard, any suggestions?

-- 
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                Professional serial bug killer

Re: printing exceptions?

[Alexandre Oliva]

On Mar  5, 2002, Bryce McKinlay <bryce@waitaki.otago.ac.nz> wrote:

> If I compile gij myself like:

> $ gcj gij.cc -I/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/
> -I/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/include
> -I./include/

> then it works fine.

> The difference is that libtool passes an explicit "-lgcc_s -lc
> -lgcc_s" to gcj (or c++?) which changes the link order so that
> libgcc_s is not linked first.

There's no reason to demand libgcc_s to be linked first.  It should
work just the same, since every other library that depends on it
should have it initialized first.

Unless gij itself had not been linked with the shared libgcc itself,
in which case it would have symbols from libgcc that would conflict
with those in the shared libgcc, and things would break.

However, gcj is supposed to link with the shared version of libgcc,
always.  Is this not happening?  What is the link command you get in
each case (please add -Wl,-v to the gcj command lines and compare the
printed link commands)

-- 
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                Professional serial bug killer

Re: printing exceptions?

[Richard Henderson]

On Wed, Mar 06, 2002 at 12:07:01AM -0300, Alexandre Oliva wrote:
> I don't understand why what you're seeing is the exact converse,
> namely, that by omitting -shared-libgcc, you get correct a working
> program&shared library, but by leaving it in, things break.
> Richard, any suggestions?

None but to actually debug it.


r~

Re: printing exceptions?

[Bryce McKinlay]

Alexandre Oliva wrote:

>What is the link command you get in
>each case (please add -Wl,-v to the gcj command lines and compare the
>printed link commands)
>

The actual "gcj" command run by libtool to generate gij in my build is:

/home/bryce/cvs/gcc/build/gcc/gcj 
-B/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/ 
-B/home/bryce/cvs/gcc/build/gcc/ -ffloat-store -g -O2 -o .libs/gij 
-shared-libgcc gij.o  
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libstdc++-v3/src 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs 
-ldl 
/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/boehm-gc/.libs/libgcjgc.so 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/../boehm-gc/.libs 
/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/zlib/.libs/libzgcj.so 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/../zlib/.libs 
-L/home/bryce/cvs/gcc/build/gcc 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../.. -lgcc_s 
-lc -lgcc_s ./../boehm-gc/.libs/libgcjgc.so -lpthread 
./../zlib/.libs/libzgcj.so 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/.libs -Wl,--rpath 
-Wl,/home/bryce/gcc31/lib

Note the "-lgcc_s -lc -lgcc_s" which is redundant, but like you say 
shouldn't cause problems. This causes gcj to link using the following 
command:

 /usr/bin/ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o .libs/gij 
/usr/lib/crt1.o /usr/lib/crti.o /home/bryce/cvs/gcc/build/gcc/crtbegin.o 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libstdc++-v3/src 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/../boehm-gc/.libs 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/../zlib/.libs 
-L/home/bryce/cvs/gcc/build/gcc 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../.. 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/.libs 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava 
-L/home/bryce/cvs/gcc/build/gcc 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../.. gij.o 
-ldl 
/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/boehm-gc/.libs/libgcjgc.so 
/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/zlib/.libs/libzgcj.so 
-lgcc_s -lc -lgcc_s ./../boehm-gc/.libs/libgcjgc.so -lpthread 
./../zlib/.libs/libzgcj.so --rpath /home/bryce/gcc31/lib -v -lgcc_s 
-lgcc -lgcj -lm -lgcjgc -lpthread -lzgcj -ldl -lgcc_s -lgcc -lc -lgcc_s 
-lgcc /home/bryce/cvs/gcc/build/gcc/crtend.o /usr/lib/crtn.o

The resulting "gij" does not work.

When I edit libtools link command, removing the "-lgcc_s -lc -lgcc_s" 
like so:

/home/bryce/cvs/gcc/build/gcc/gcj 
-B/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/ 
-B/home/bryce/cvs/gcc/build/gcc/ -ffloat-store -g -O2 -o .libs/gij 
-shared-libgcc gij.o  
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libstdc++-v3/src 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs 
-ldl 
/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/boehm-gc/.libs/libgcjgc.so 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/../boehm-gc/.libs 
/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/zlib/.libs/libzgcj.so 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/../zlib/.libs 
-L/home/bryce/cvs/gcc/build/gcc 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../.. 
./../boehm-gc/.libs/libgcjgc.so -lpthread ./../zlib/.libs/libzgcj.so 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/.libs -Wl,--rpath 
-Wl,/home/bryce/gcc31/lib

It results in the following link command:

 /usr/bin/ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o .libs/gij 
/usr/lib/crt1.o /usr/lib/crti.o /home/bryce/cvs/gcc/build/gcc/crtbegin.o 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libstdc++-v3/src 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/../boehm-gc/.libs 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/../zlib/.libs 
-L/home/bryce/cvs/gcc/build/gcc 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../.. 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava/.libs 
-L/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/libjava 
-L/home/bryce/cvs/gcc/build/gcc 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2 
-L/home/bryce/gcc31/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../.. gij.o 
-ldl 
/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/boehm-gc/.libs/libgcjgc.so 
/home/bryce/cvs/gcc/build/i686-pc-linux-gnu/zlib/.libs/libzgcj.so 
./../boehm-gc/.libs/libgcjgc.so -lpthread ./../zlib/.libs/libzgcj.so 
--rpath /home/bryce/gcc31/lib -v -lgcc_s -lgcc -lgcj -lm -lgcjgc 
-lpthread -lzgcj -ldl -lgcc_s -lgcc -lc -lgcc_s -lgcc 
/home/bryce/cvs/gcc/build/gcc/crtend.o /usr/lib/crtn.o

And the "gij" produced by this command works perfectly. Maybe it has 
something to do with -lpthread?

regards

Bryce.

Re: printing exceptions?

[Jeff Sturm]

On Wed, 6 Mar 2002, Bryce McKinlay wrote:
> And the "gij" produced by this command works perfectly. Maybe it has 
> something to do with -lpthread?

You must never link -lc ahead of -lpthread.  The latter often overrides
symbols in the former (e.g. wait).

Jeff

Re: printing exceptions?

[Adam Megacz]

Jeff Sturm <jsturm@one-point.com> writes:
> You must never link -lc ahead of -lpthread.  The latter often overrides
> symbols in the former (e.g. wait).

BTW, why does the order of -l arguments matter?

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: printing exceptions?

[Jeff Sturm]

On 6 Mar 2002, Adam Megacz wrote:
> > You must never link -lc ahead of -lpthread.  The latter often overrides
> > symbols in the former (e.g. wait).
> 
> BTW, why does the order of -l arguments matter?

The runtime linker resolves symbols by searching libraries in link order.
The order is only important if symbols are duplicated, as in
libpthread.so:

[jsturm@suzy jsturm]$ readelf -s /lib/libpthread.so.0 | grep fork
   218: 00008650   198 FUNC    WEAK   DEFAULT   12 fork@@GLIBC_2.0

[jsturm@suzy jsturm]$ readelf -s /lib/libc.so.6 | grep fork
  1241: 000bb160    50 FUNC    WEAK   DEFAULT   11 fork@@GLIBC_2.0

(output trimmed for clarity.)

By placing -lc first, you will bind to the wrong implementation of fork().

Jeff

Re: printing exceptions?

[Alexandre Oliva]

On Mar  6, 2002, Jeff Sturm <jsturm@one-point.com> wrote:

> On Wed, 6 Mar 2002, Bryce McKinlay wrote:
>> And the "gij" produced by this command works perfectly. Maybe it has 
>> something to do with -lpthread?

> You must never link -lc ahead of -lpthread.  The latter often overrides
> symbols in the former (e.g. wait).

Yup, that sounds like a good lead.

The solution to make sure pthread is always linked in before libc
would be to explicitly link -lpthread before any other library (even
GCJ-internal ones, even if it is going to be duplicated afterwards).
Another, slightly uglier solution, would be to make sure the first
library dependency of libjava also depends on -lpthread, such that the
-lgcc_s -lc -lgcc_s that comes in with it (because it actually depends
on those libraries) doesn't end up before -lpthread.

-- 
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                Professional serial bug killer

Re: printing exceptions?

[Tom Tromey]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

Alexandre> The solution to make sure pthread is always linked in
Alexandre> before libc would be to explicitly link -lpthread before
Alexandre> any other library (even GCJ-internal ones, even if it is
Alexandre> going to be duplicated afterwards).

Is there something definitely wrong with just changing --tag=CXX to
--tag=CC?

Otherwise won't we need to link against -lpthread twice?  E.g.:

    gij_LDADD = $(THREADLIBS) libgcj.la $(GCLIBS) $(THREADLIBS) [ ... ]

That seems ugly.

Tom

Re: printing exceptions?

[Alexandre Oliva]

On Mar  6, 2002, Tom Tromey <tromey@redhat.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> The solution to make sure pthread is always linked in
Alexandre> before libc would be to explicitly link -lpthread before
Alexandre> any other library (even GCJ-internal ones, even if it is
Alexandre> going to be duplicated afterwards).

> Is there something definitely wrong with just changing --tag=CXX to
> --tag=CC?

Yes.  You won't get the program linked with the shared libgcc if you
change the tag.  CC doesn't link with shared libgcc, CXX does.

> Otherwise won't we need to link against -lpthread twice?  E.g.:

>     gij_LDADD = $(THREADLIBS) libgcj.la $(GCLIBS) $(THREADLIBS) [ ... ]

> That seems ugly.

Actually, I was thinking of libgcj.la being linked with $(THREADLIBS)
first, which would solve the problem just the same.  Unless gij is
linked with some other library that would bring libc in first.

-- 
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                Professional serial bug killer

Re: printing exceptions?

[Tom Tromey]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

Alexandre> Actually, I was thinking of libgcj.la being linked with
Alexandre> $(THREADLIBS) first, which would solve the problem just the
Alexandre> same.

We already do that:

    libgcj_la_LDFLAGS = -rpath $(toolexeclibdir) $(THREADLIBS) $(LIBLTDL) \
	    $(GCLIBS) $(ZLIBS) \

So something else must be required.

Tom

Re: printing exceptions?

[Alexandre Oliva]

On Mar  6, 2002, Tom Tromey <tromey@redhat.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> Actually, I was thinking of libgcj.la being linked with
Alexandre> $(THREADLIBS) first, which would solve the problem just the
Alexandre> same.

> We already do that:

>     libgcj_la_LDFLAGS = -rpath $(toolexeclibdir) $(THREADLIBS) $(LIBLTDL) \
> 	    $(GCLIBS) $(ZLIBS) \

> So something else must be required.

Do we need any configure option to get THREADLIBS set?  Why isn't it
enabled by default?  Since GCC moved to enabling threads by default, I
think it would be reasonable for libjava to do so too, no?

-- 
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                Professional serial bug killer

Re: printing exceptions?

[Tom Tromey]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

>> libgcj_la_LDFLAGS = -rpath $(toolexeclibdir) $(THREADLIBS) $(LIBLTDL) \
>> $(GCLIBS) $(ZLIBS) \

Alexandre> Do we need any configure option to get THREADLIBS set?  Why
Alexandre> isn't it enabled by default?  Since GCC moved to enabling
Alexandre> threads by default, I think it would be reasonable for
Alexandre> libjava to do so too, no?

We get the thread model by asking gcc:

    THREADS=`$CC -v 2>&1 | sed -n 's/^Thread model: //p'`

We use that to compute what we need.

Tom

Re: printing exceptions?

[Alexandre Oliva]

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

On Mar  6, 2002, Tom Tromey <tromey@redhat.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> Actually, I was thinking of libgcj.la being linked with
Alexandre> $(THREADLIBS) first, which would solve the problem just the
Alexandre> same.

> We already do that:

>     libgcj_la_LDFLAGS = -rpath $(toolexeclibdir) $(THREADLIBS) $(LIBLTDL) \
> 	    $(GCLIBS) $(ZLIBS) \

> So something else must be required.

Ok, I see the problem now.  It's indeed a bug in libtool.

Basically, the problem is that libtool sometimes decides it can drop
duplicate -l flags from the command line, when it thinks it is safe to
do so.  Currently, the rules is that, if a library does not explicitly
appear more than once in the dependency list of a library, libtool
assumes there's no problem if it simply discards any previous
occurrences of such a library.  On the other hand, if a library
appears more than once in a dependency list (say, libjava is linked
with -lgcc_s -lc -lgcc_s), libtool considers the duplicate library as
a special library that strongly depends on ordering, and does not move
it.

The problem is that -lpthread ends up being removed from before the
first copy of -lgcc_s, because it is not explicitly duplicated and
thus it's taken as a movable library, while the first copy of -lgcc_s
remains, as it is taken as unmovable.

I don't see an easy way to fix this problem in libtool.  It would
require every unmovable library to establish a barrier such that no
libraries that appear before it can be dropped.  Since every C++
library has -lgcc_s -lc -lgcc_s in its dependency list, this would
defeat the whole purpose of the duplicate-removal of dependencies,
that was an absolute must for large packages with hundreds of
libraries, such as KDE.  Without such an optimization, building KDE
would easily overflow the command line size on most, if not all OSs
(except any one that does not impose fixed limits on command line
sizes), due to exponential explosion of `-lm -lgcc -lc -lgcc' in the
command line.

Ideally, libtool should try to tell whether a library is dynamic or
static in order to decide whether to eliminate all but the first or
all but the last duplicates of -l flags (except for static libraries
marked as special), but I'm not even sure this would be correct.

Anyway, there are several ways to alleviate the impact of this problem
in libjava and GCC.

The simplest solution I could come up with was to drop from the link
command of executables any libraries that were already in the
dependency list of libgcj, so they'd be automatically brought in.
This was enough to fix the problem at hand: now gij is linked with
-lpthread before -lgcc_s, since there's no duplicate of -lpthread
after the first implicit occurrence of -lgcc_s that was brought in
from libgcj.la itself.  The patch that fixes this problem is
attached.

Another possibility that occurred to me, that would further alleviate
the problem of duplicate shared libraries, would be to get GCC to no
longer issue the `-lgcc_s -lc -lgcc_s' sequence, but instead, to use
just `-lgcc_s -lc'.  I believe this would be a perfectly safe thing to
do in the context of a shared -lgcc_s, no?  We'd might still have to
add duplicates for -lgcc and -lgcc_eh, so it might end up not being of
much help.  It's probably worth a shot, though.  Any opposition to my
changing the GCC specs to that effect?

Yet another solution would be to get libtool to recognize libraries
and object files implicitly linked in especially.  It already does
something to that effect, but it still considers duplicate libraries
at such points as special.  Sometimes I think adding the code to peek
into the flags implicitly passed by g++ to the linker was a mistake,
but then I think of how nice it is to be able to link with a libtool
(possibly static) library using `libtool gcc', even if the library
itself contains C++ code and has to be linked with -lstdc++, with the
certainty that libtool will add the -lstdc++ dependency by itself
since it learned about such dependency when looking at the arguments
g++ passed to the linker when creating the original library.  And
then, sometimes libtool just can't use (old versions of) g++ to link
shared libraries, because they're broken, and then it's essential for
it to figure out which flags g++ would pass to the linker, drop those
that would break (such as static libstdc++ that can't be linked into a
shared library) and go with the rest of the args running the linker
directly.

Other libtoolers, any further suggestions as to how to fix this real
libtool bug?

Anyway, here's the patch for libjava.  I'm checking it in mainline and
in the 3.1 branch.  Bootstrapped on athlon-pc-linux-gnu with
--enable-threads, and verified by visual inspection that the link
command line of gij and other libjava executables did contain
-lpthread before -lgcc_s -lc -lgcc_s.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libjava-no-deplibs.patch --]
[-- Type: text/x-patch, Size: 2499 bytes --]

Index: libjava/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* Makefile.am (jv_convert_LDADD): Don't list libraries that are
	already implicitly brought in from libgcj.la.
	(gij_LDADD, rmic_LDADD, rmiregistry_LDADD): Likewise.
	* Makefile.in: Rebuilt.

Index: libjava/Makefile.am
===================================================================
RCS file: /cvs/gcc/egcs/libjava/Makefile.am,v
retrieving revision 1.205
diff -u -p -r1.205 Makefile.am
--- libjava/Makefile.am 2002/03/06 18:54:35 1.205
+++ libjava/Makefile.am 2002/03/15 22:14:58
@@ -429,7 +429,7 @@ jv_convert_LINK = $(GCJLINK)
 ## system libraries we need (via the specs file).
 ## We need the -L so that gcj can find libgcj with `-lgcj'.
 ## FIXME: should be _libs on some systems.
-jv_convert_LDADD = libgcj.la $(GCLIBS) $(THREADLIBS) $(ZLIBS) -L$(here)/.libs
+jv_convert_LDADD = libgcj.la -L$(here)/.libs
 ## Depend on the spec file to make sure it is up to date before
 ## linking this program.
 jv_convert_DEPENDENCIES = $(convert_source_files:.java=.lo) \
@@ -446,7 +446,7 @@ gij_LINK = $(GCJLINK)
 ## system libraries we need (via the specs file).
 ## We need the -L so that gcj can find libgcj with `-lgcj'.
 ## FIXME: should be _libs on some systems.
-gij_LDADD = libgcj.la $(GCLIBS) $(THREADLIBS) $(ZLIBS) -L$(here)/.libs
+gij_LDADD = libgcj.la -L$(here)/.libs
 ## Depend on the spec file to make sure it is up to date before
 ## linking this program.
 gij_DEPENDENCIES = $(GCDEPS) $(THREADDEPS) $(ZDEPS) libgcj.la libgcj.spec
@@ -462,7 +462,7 @@ rmic_LINK = $(GCJLINK)
 ## system libraries we need (via the specs file).
 ## We need the -L so that gcj can find libgcj with `-lgcj'.
 ## FIXME: should be _libs on some systems.
-rmic_LDADD = libgcj.la $(GCLIBS) $(THREADLIBS) $(ZLIBS) -L$(here)/.libs
+rmic_LDADD = libgcj.la -L$(here)/.libs
 ## Depend on the spec file to make sure it is up to date before
 ## linking this program.
 rmic_DEPENDENCIES = $(GCDEPS) $(THREADDEPS) $(ZDEPS) libgcj.la libgcj.spec
@@ -478,7 +478,7 @@ rmiregistry_LINK = $(GCJLINK)
 ## system libraries we need (via the specs file).
 ## We need the -L so that gcj can find libgcj with `-lgcj'.
 ## FIXME: should be _libs on some systems.
-rmiregistry_LDADD = libgcj.la $(GCLIBS) $(THREADLIBS) $(ZLIBS) -L$(here)/.libs
+rmiregistry_LDADD = libgcj.la -L$(here)/.libs
 ## Depend on the spec file to make sure it is up to date before
 ## linking this program.
 rmiregistry_DEPENDENCIES = $(GCDEPS) $(THREADDEPS) $(ZDEPS) libgcj.la libgcj.spec

[-- Attachment #3: Type: text/plain, Size: 289 bytes --]


-- 
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                Professional serial bug killer

Re: printing exceptions?

[Richard Henderson]

On Fri, Mar 15, 2002 at 07:43:43PM -0300, Alexandre Oliva wrote:
> Another possibility that occurred to me, that would further alleviate
> the problem of duplicate shared libraries, would be to get GCC to no
> longer issue the `-lgcc_s -lc -lgcc_s' sequence, but instead, to use
> just `-lgcc_s -lc'.

Seems ok.

> We'd might still have to add duplicates for -lgcc and -lgcc_eh...

Not for gcc_eh.  The point of the duplicate is to cater to a libc
that uses e.g. __divdi3.  I suspect that we can use

	-lgcc_eh -lgcc -lc -lgcc

in the static case.


r~

Re: printing exceptions?

[Alexandre Oliva]

On Mar 15, 2002, Richard Henderson <rth@redhat.com> wrote:

> On Fri, Mar 15, 2002 at 07:43:43PM -0300, Alexandre Oliva wrote:
>> Another possibility that occurred to me, that would further alleviate
>> the problem of duplicate shared libraries, would be to get GCC to no
>> longer issue the `-lgcc_s -lc -lgcc_s' sequence, but instead, to use
>> just `-lgcc_s -lc'.

> Seems ok.

Yay!  I'll try to implement this in the next few days.

>> We'd might still have to add duplicates for -lgcc and -lgcc_eh...

> Not for gcc_eh.  The point of the duplicate is to cater to a libc
> that uses e.g. __divdi3.

More specifically, and static libc that uses __divdi3, since a shared
one would have its own __divdi3, no?

However, I kind of fail to see the point of having -lgcc before -lc.
I understand the idea is to resolve symbols of the program with the
implementations in libgcc, but what if the program doesn't reference a
symbol, but libc does?  Then, we won't get the definition from libgcc,
but rather from libc itself.  Could this ever be a problem?  If not,
why don't we just drop the -lgcc from before -lc and stick with the
one after -lc only?

-- 
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                Professional serial bug killer

Re: printing exceptions?

[Richard Henderson]

On Fri, Mar 15, 2002 at 08:35:39PM -0300, Alexandre Oliva wrote:
> More specifically, and static libc that uses __divdi3, since a shared
> one would have its own __divdi3, no?

In theory.  But I wouldn't expect static libc to have a different
set of symbols than shared libc.  *shrug*

> However, I kind of fail to see the point of having -lgcc before -lc.

There are symbols in libgcc that require symbols from libc.  
Ideally we'd be using some permutation of

	--start-group -lgcc_eh -lgcc -lc --end-group

but that's a gnu ld thing.


r~

Re: printing exceptions?

[Andreas Schwab]

Alexandre Oliva <aoliva@redhat.com> writes:

|> However, I kind of fail to see the point of having -lgcc before -lc.

The point of having -lgcc before -lc is that -lgcc can add references to
-lc functions that were not referenced before.  If you have -lgcc only
after -lc those references cannot be resolved in a static link.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: printing exceptions?

[Jakub Jelinek]

On Sat, Mar 16, 2002 at 01:02:51AM +0100, Andreas Schwab wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
> 
> |> However, I kind of fail to see the point of having -lgcc before -lc.
> 
> The point of having -lgcc before -lc is that -lgcc can add references to
> -lc functions that were not referenced before.  If you have -lgcc only
> after -lc those references cannot be resolved in a static link.

Though for !static !shared-libgcc, I think:
-lc -lgcc -lc_nonshared
is best, so that symbols are preferably satisfied from shared libc.

	Jakub

Re: printing exceptions?

[Alexandre Oliva]

On Mar 15, 2002, Andreas Schwab <schwab@suse.de> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
> |> However, I kind of fail to see the point of having -lgcc before -lc.

> The point of having -lgcc before -lc is that -lgcc can add references to
> -lc functions that were not referenced before.

Oh!  Yes, indeed.  I forgot about that.  Thanks for the reminder.

So, -lgcc -lc -lgcc is indeed one of the special cases that libtool is
going to have to learn to live with.  Perhaps it could learn to treat
them as a unit, though...

Fortunately, libtool only peeks into flags implicitly passed to the
linker in non-C tags, which means we're only going to get -lgcc_s
(because of the implicit -shared-libgcc in g++ and gcj), and things
will Just Work (TM).

-- 
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                Professional serial bug killer

Re: printing exceptions?

[Alexandre Oliva]

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

On Mar 15, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Mar 15, 2002, Richard Henderson <rth@redhat.com> wrote:
>> On Fri, Mar 15, 2002 at 07:43:43PM -0300, Alexandre Oliva wrote:
>>> Another possibility that occurred to me, that would further alleviate
>>> the problem of duplicate shared libraries, would be to get GCC to no
>>> longer issue the `-lgcc_s -lc -lgcc_s' sequence, but instead, to use
>>> just `-lgcc_s -lc'.

>> Seems ok.

> Yay!  I'll try to implement this in the next few days.

Err...  For large values of `few' :-(

Here's the patch I came up with, that I've already done some testing
with, and that's undergoing bootstrapping now.  Ok to install?
Perhaps even in 3.1?  Can anybody think of further libraries that
could be removed from the former second expansion of %G?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libgcc-libc-spec.patch --]
[-- Type: text/x-patch, Size: 3787 bytes --]

Index: gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* gcc.c (LIBGCC_SPEC): Folded %L and duplicate %G here...
	(LINK_COMMAND_SPEC): ... from here.
	(init_gcc_specs): Duplicate it here too, omitting 
	shared_name in the second copy.
	(init_spec): Test for duplicate
	* config/i386/djgpp.h (LINK_COMMAND_SPEC): Remove `%L %G'.

Index: gcc/gcc.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/gcc.c,v
retrieving revision 1.304
diff -u -p -r1.304 gcc.c
--- gcc/gcc.c 2002/03/26 21:38:40 1.304
+++ gcc/gcc.c 2002/03/30 09:07:56
@@ -558,9 +558,9 @@ proper position among the other output f
 #ifndef LIBGCC_SPEC
 #if defined(LINK_LIBGCC_SPECIAL) || defined(LINK_LIBGCC_SPECIAL_1)
 /* Have gcc do the search for libgcc.a.  */
-#define LIBGCC_SPEC "libgcc.a%s"
+#define LIBGCC_SPEC "libgcc.a%s %L libgcc.a%s"
 #else
-#define LIBGCC_SPEC "-lgcc"
+#define LIBGCC_SPEC "-lgcc %L -lgcc"
 #endif
 #endif
 
@@ -620,7 +620,7 @@ proper position among the other output f
 %{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
     %(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t}\
     %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}\
-    %{static:} %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%G %L %G}}\
+    %{static:} %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%G}}\
     %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}"
 #endif
 
@@ -1426,7 +1426,16 @@ init_gcc_specs (obstack, shared_name, st
 #else
 		shared_name,
 #endif
-		"}}}", NULL);
+		"}}} %L ",
+		"%{static|static-libgcc:", static_name, " ", eh_name,
+		"}%{!static:%{!static-libgcc:",
+		"%{!shared:%{!shared-libgcc:", static_name, " ",
+		eh_name, "}%{shared-libgcc:",
+		static_name, "}}",
+#ifdef LINK_EH_SPEC
+		"%{shared:%{!shared-libgcc:", static_name, "}}",
+#endif
+		"}}", NULL);
 
   obstack_grow (obstack, buf, strlen (buf));
   free (buf);
@@ -1507,7 +1516,7 @@ init_spec ()
        when given the proper command line arguments.  */
     while (*p)
       {
-        if (in_sep && *p == '-' && strncmp (p, "-lgcc", 5) == 0)
+        if (in_sep && *p == '-' && strncmp (p, "-lgcc %L -lgcc", 14) == 0)
 	  {
 	    init_gcc_specs (&obstack,
 #ifdef NO_SHARED_LIBGCC_MULTILIB
@@ -1518,10 +1527,11 @@ init_spec ()
 			    ,
 			    "-lgcc",
 			    "-lgcc_eh");
-	    p += 5;
+	    p += 14;
 	    in_sep = 0;
 	  }
-	else if (in_sep && *p == 'l' && strncmp (p, "libgcc.a%s", 10) == 0)
+	else if (in_sep && *p == 'l'
+		 && strncmp (p, "libgcc.a%s %L libgcc.a%s", 24) == 0)
 	  {
 	    /* Ug.  We don't know shared library extensions.  Hope that
 	       systems that use this form don't do shared libraries.  */
@@ -1534,7 +1544,7 @@ init_spec ()
 			    ,
 			    "libgcc.a%s",
 			    "libgcc_eh.a%s");
-	    p += 10;
+	    p += 24;
 	    in_sep = 0;
 	  }
 	else
Index: gcc/config/i386/djgpp.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/djgpp.h,v
retrieving revision 1.33
diff -u -p -r1.33 djgpp.h
--- gcc/config/i386/djgpp.h 2002/01/28 18:11:13 1.33
+++ gcc/config/i386/djgpp.h 2002/03/30 09:07:56
@@ -1,5 +1,5 @@
 /* Configuration for an i386 running MS-DOS with DJGPP.
-   Copyright (C) 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
+   Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
 
 This file is part of GNU CC.
 
@@ -106,7 +106,7 @@ Boston, MA 02111-1307, USA.  */
 \t%{r} %{s} %{t} %{u*} %{x} %{z} %{Z}\
 \t%{!A:%{!nostdlib:%{!nostartfiles:%S}}}\
 \t%{static:} %{L*} %D %o\
-\t%{!nostdlib:%{!nodefaultlibs:%G %L %G}}\
+\t%{!nostdlib:%{!nodefaultlibs:%G}}\
 \t%{!A:%{!nostdlib:%{!nostartfiles:%E}}}\
 \t-Tdjgpp.djl %{T*}}}}}}}\n\
 %{!c:%{!M:%{!MM:%{!E:%{!S:stubify %{v} %{o*:%*} %{!o*:a.out} }}}}}"

[-- Attachment #3: Type: text/plain, Size: 289 bytes --]


-- 
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                Professional serial bug killer

Re: printing exceptions?

[Richard Henderson]

On Sat, Mar 30, 2002 at 06:18:19AM -0300, Alexandre Oliva wrote:
> 	* gcc.c (LIBGCC_SPEC): Folded %L and duplicate %G here...
> 	(LINK_COMMAND_SPEC): ... from here.
> 	(init_gcc_specs): Duplicate it here too, omitting 
> 	shared_name in the second copy.
> 	(init_spec): Test for duplicate
> 	* config/i386/djgpp.h (LINK_COMMAND_SPEC): Remove `%L %G'.

Ok.


r~

Re: printing exceptions?

[Alexandre Oliva]

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

On Mar 30, 2002, Richard Henderson <rth@redhat.com> wrote:

> On Sat, Mar 30, 2002 at 06:18:19AM -0300, Alexandre Oliva wrote:
>> * gcc.c (LIBGCC_SPEC): Folded %L and duplicate %G here...
>> (LINK_COMMAND_SPEC): ... from here.
>> (init_gcc_specs): Duplicate it here too, omitting 
>> shared_name in the second copy.
>> (init_spec): Test for duplicate
>> * config/i386/djgpp.h (LINK_COMMAND_SPEC): Remove `%L %G'.

> Ok.

Hmm...  Unfortunately this broke libjava's overriding of the lib spec,
introducing infinite mutual recursion between the overridden libc and
libgcc.  I wonder if this means we shouldn't mess up with the lib
spec...

Anyway, here's a patch that adjusts libjava specs to work with the
reworked specs.  

This time, bootstrap is complete, and libjava testing looks good
(except for a number of ICEs that were already present before).

There are no changes in the patch for gcc, only changes in libjava
were added.

Ok to install?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libgcc-libc-spec.patch --]
[-- Type: text/x-patch, Size: 5332 bytes --]

Index: gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* gcc.c (LIBGCC_SPEC): Folded %L and duplicate %G here...
	(LINK_COMMAND_SPEC): ... from here.
	(init_gcc_specs): Duplicate it here too, omitting 
	shared_name in the second copy.
	(init_spec): Test for duplicate
	* config/i386/djgpp.h (LINK_COMMAND_SPEC): Remove `%L %G'.

Index: gcc/gcc.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/gcc.c,v
retrieving revision 1.304
diff -u -p -r1.304 gcc.c
--- gcc/gcc.c 2002/03/26 21:38:40 1.304
+++ gcc/gcc.c 2002/03/30 09:07:56
@@ -558,9 +558,9 @@ proper position among the other output f
 #ifndef LIBGCC_SPEC
 #if defined(LINK_LIBGCC_SPECIAL) || defined(LINK_LIBGCC_SPECIAL_1)
 /* Have gcc do the search for libgcc.a.  */
-#define LIBGCC_SPEC "libgcc.a%s"
+#define LIBGCC_SPEC "libgcc.a%s %L libgcc.a%s"
 #else
-#define LIBGCC_SPEC "-lgcc"
+#define LIBGCC_SPEC "-lgcc %L -lgcc"
 #endif
 #endif
 
@@ -620,7 +620,7 @@ proper position among the other output f
 %{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
     %(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t}\
     %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}\
-    %{static:} %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%G %L %G}}\
+    %{static:} %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%G}}\
     %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}"
 #endif
 
@@ -1426,7 +1426,16 @@ init_gcc_specs (obstack, shared_name, st
 #else
 		shared_name,
 #endif
-		"}}}", NULL);
+		"}}} %L ",
+		"%{static|static-libgcc:", static_name, " ", eh_name,
+		"}%{!static:%{!static-libgcc:",
+		"%{!shared:%{!shared-libgcc:", static_name, " ",
+		eh_name, "}%{shared-libgcc:",
+		static_name, "}}",
+#ifdef LINK_EH_SPEC
+		"%{shared:%{!shared-libgcc:", static_name, "}}",
+#endif
+		"}}", NULL);
 
   obstack_grow (obstack, buf, strlen (buf));
   free (buf);
@@ -1507,7 +1516,7 @@ init_spec ()
        when given the proper command line arguments.  */
     while (*p)
       {
-        if (in_sep && *p == '-' && strncmp (p, "-lgcc", 5) == 0)
+        if (in_sep && *p == '-' && strncmp (p, "-lgcc %L -lgcc", 14) == 0)
 	  {
 	    init_gcc_specs (&obstack,
 #ifdef NO_SHARED_LIBGCC_MULTILIB
@@ -1518,10 +1527,11 @@ init_spec ()
 			    ,
 			    "-lgcc",
 			    "-lgcc_eh");
-	    p += 5;
+	    p += 14;
 	    in_sep = 0;
 	  }
-	else if (in_sep && *p == 'l' && strncmp (p, "libgcc.a%s", 10) == 0)
+	else if (in_sep && *p == 'l'
+		 && strncmp (p, "libgcc.a%s %L libgcc.a%s", 24) == 0)
 	  {
 	    /* Ug.  We don't know shared library extensions.  Hope that
 	       systems that use this form don't do shared libraries.  */
@@ -1534,7 +1544,7 @@ init_spec ()
 			    ,
 			    "libgcc.a%s",
 			    "libgcc_eh.a%s");
-	    p += 10;
+	    p += 24;
 	    in_sep = 0;
 	  }
 	else
Index: gcc/config/i386/djgpp.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/i386/djgpp.h,v
retrieving revision 1.33
diff -u -p -r1.33 djgpp.h
--- gcc/config/i386/djgpp.h 2002/01/28 18:11:13 1.33
+++ gcc/config/i386/djgpp.h 2002/03/30 09:07:56
@@ -1,5 +1,5 @@
 /* Configuration for an i386 running MS-DOS with DJGPP.
-   Copyright (C) 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
+   Copyright (C) 1997, 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
 
 This file is part of GNU CC.
 
@@ -106,7 +106,7 @@ Boston, MA 02111-1307, USA.  */
 \t%{r} %{s} %{t} %{u*} %{x} %{z} %{Z}\
 \t%{!A:%{!nostdlib:%{!nostartfiles:%S}}}\
 \t%{static:} %{L*} %D %o\
-\t%{!nostdlib:%{!nodefaultlibs:%G %L %G}}\
+\t%{!nostdlib:%{!nodefaultlibs:%G}}\
 \t%{!A:%{!nostdlib:%{!nostartfiles:%E}}}\
 \t-Tdjgpp.djl %{T*}}}}}}}\n\
 %{!c:%{!M:%{!MM:%{!E:%{!S:stubify %{v} %{o*:%*} %{!o*:a.out} }}}}}"
Index: libjava/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* libgcj.spec.in: Override libgcc, not lib.
	* libgcj-test.spec.in: Likewise.

Index: libjava/libgcj.spec.in
===================================================================
RCS file: /cvs/gcc/egcs/libjava/libgcj.spec.in,v
retrieving revision 1.21
diff -u -p -r1.21 libgcj.spec.in
--- libjava/libgcj.spec.in 2002/03/27 16:41:35 1.21
+++ libjava/libgcj.spec.in 2002/03/31 00:56:28
@@ -3,7 +3,7 @@
 # It is used to specify the standard libraries we need in order
 # to link with libgcj.
 #
-%rename lib liborig
-*lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) %(liborig)
+%rename libgcc libgccorig
+*libgcc: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgccorig)
 
 *jc1: @HASH_SYNC_SPEC@ @DIVIDESPEC@ @CHECKREFSPEC@ @JC1GCSPEC@ @EXCEPTIONSPEC@ -fkeep-inline-functions
Index: libjava/libgcj-test.spec.in
===================================================================
RCS file: /cvs/gcc/egcs/libjava/libgcj-test.spec.in,v
retrieving revision 1.1
diff -u -p -r1.1 libgcj-test.spec.in
--- libjava/libgcj-test.spec.in 2000/03/04 21:50:19 1.1
+++ libjava/libgcj-test.spec.in 2002/03/31 00:56:28
@@ -2,6 +2,6 @@
 # This spec file is read by gcj when linking.
 # It is only used by the testing harnesses (in libjava and gdb).
 #
-%rename lib liborig2
-*lib: @LIBGCJTESTSPEC@ @GCTESTSPEC@ @ZLIBTESTSPEC@ %(liborig2)
+%rename libgcc libgccorig2
+*libgcc: @LIBGCJTESTSPEC@ @GCTESTSPEC@ @ZLIBTESTSPEC@ %(libgccorig2)
 

[-- Attachment #3: Type: text/plain, Size: 289 bytes --]


-- 
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                Professional serial bug killer

Re: printing exceptions?

[Richard Henderson]

On Sat, Mar 30, 2002 at 10:02:53PM -0300, Alexandre Oliva wrote:
> Anyway, here's a patch that adjusts libjava specs to work with the
> reworked specs.  

Ok.


r~

Re: printing exceptions?

[Tom Tromey]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

Alexandre> This time, bootstrap is complete, and libjava testing looks
Alexandre> good (except for a number of ICEs that were already present
Alexandre> before).

What platform is this?  How did you test?
On x86 I currently see 0 FAIL.

Anyway I'm sure the patch is fine.

Tom

Re: printing exceptions?

[Alexandre Oliva]

On Mar 31, 2002, Tom Tromey <tromey@redhat.com> wrote:

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
Alexandre> This time, bootstrap is complete, and libjava testing looks
Alexandre> good (except for a number of ICEs that were already present
Alexandre> before).

> What platform is this?

Oops.  Forgot to mention.  athlon-pc-linux-gnu

> How did you test?

make check-target-libjava (in the build tree).

> On x86 I currently see 0 FAIL.

Perhaps you got Jan's fix already.  I still had a number of crashes in
flow.

> Anyway I'm sure the patch is fine.

Thanks, it's in mainline now, installing in the 3.1 branch in the next
few minutes.

-- 
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                Professional serial bug killer

Re: printing exceptions?

[Krister Walfridsson]

On 30 Mar 2002, Alexandre Oliva wrote:
>        * gcc.c (LIBGCC_SPEC): Folded %L and duplicate %G here...
>        (LINK_COMMAND_SPEC): ... from here.
>        (init_gcc_specs): Duplicate it here too, omitting
>        shared_name in the second copy.
>        (init_spec): Test for duplicate


This change to gcc.c breaks bootstrap on i386-unknown-netbsdelf1.5ZC.

What happens is that the linker gets incorrect options when trying
to link gengenrtl. Before this change it was passed

   stage1/collect2 -dc -dp -e __start -dynamic-linker /usr/libexec/ld.elf_so -o gengenrtl /usr/lib/crt0.o /usr/lib/crtbegin.o -Lstage1 gengenrtl.o ../libiberty/libiberty.a -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/lib/crtend.o

and after

   stage1/collect2 -dc -dp -e __start -dynamic-linker /usr/libexec/ld.elf_so -o gengenrtl /usr/lib/crt0.o /usr/lib/crtbegin.o -Lstage1 gengenrtl.o ../libiberty/libiberty.a -lgcc /usr/lib/crtend.o

   /Krister

Re: printing exceptions?

[Alexandre Oliva]

On Mar 31, 2002, Krister Walfridsson <cato@df.lth.se> wrote:

> On 30 Mar 2002, Alexandre Oliva wrote:
>> * gcc.c (LIBGCC_SPEC): Folded %L and duplicate %G here...
>> (LINK_COMMAND_SPEC): ... from here.
>> (init_gcc_specs): Duplicate it here too, omitting
>> shared_name in the second copy.
>> (init_spec): Test for duplicate


> This change to gcc.c breaks bootstrap on i386-unknown-netbsdelf1.5ZC.

Hmm...  I see.  I had failed to look for a number of different
definitions of LIBGCC_SPEC in config files.  There are lots of them
:-(  I guess I'll have to come up with something different.  I've
reverted my patch for now.  Thanks for the quick feedback.

-- 
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                Professional serial bug killer

Re: printing exceptions?

[mike stump]

> To: Richard Henderson <rth@redhat.com>
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 15 Mar 2002 20:35:39 -0300

> However, I kind of fail to see the point of having -lgcc before -lc.

Examine libgcc.a for any symbols that can only be satisfied from
libc.a.  One would need --group to make this work, that, or else one
would need to put -lgcc before -lc.