libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Libtool stresstest.at segfault on Cygwin/MinGW


From: Peter Ekberg
Subject: RE: Libtool stresstest.at segfault on Cygwin/MinGW
Date: Fri, 16 Sep 2005 11:11:29 +0200

* Peter Ekberg wrote on Thursday, September 15, 2005 15:15 CEST:

It's me again...

> * Peter Ekberg wrote on Tuesday, September 13, 2005 10:55 CEST:
> > * Ralf Wildenhues wrote on Tuesday, September 13, 2005 08:25 CEST:
> > > Hi Peter, 
> > > 
> > > Peter Ekberg writes:
> > > > make check TESTS="" TESTSUITE_FLAGS='-v -d 22'. 
> > > > 
> > > > As you can see, it goes on for quite a while before it 
> segfaults,
> > > > and no sign of the errors you see. I had a breif look at this
> > > > new bug and it looks as if there's a problem when accessing v7
> > > > or v8 (first line in main in main.c, line 90 in stresstest.at) 
> > > > 
> > > > Perhaps something along the lines of: 
> > > > 
> > > > http://cygwin.com/ml/cygwin/2004-09/msg01101.html 
> > > > 
> > > > I think this bug is present for all of MSVC, MinGW and Cygwin,
> > > > so it smells like some generic windows problem...
> > > 
> > > Let's see about this later. 
> > 
> > I now think this is more likely this problem instead:
> > 
> > http://sources.redhat.com/ml/binutils/2004-02/msg00003.html
> > 
> > The bug is present using at least Cygwin/gcc 3.3.3 and 
> > MinGW/gcc 3.2.3.
> > 
> > It was a bitch to check if MSVC is affected. The test bugged out
> > earlier and was terminated before the interesting part.
> > 
> > I really think stresstest.at should be broken up in more tests. As
> > is, it is PITA to debug problems found by it. Appart from the
> > difficulty in seeing exactly what went wrong, it is also not
> > possible (?) to skip ahead to the test you're interested in which
> > is a big waste of time. It would be valuable to run all tests (or
> > at least more tests) even if some of them fails.
> > 
> > Anyway, after rearranging the loops so that '-export-symbols asyms'
> > is first in the l2 loop and '-rpath /nonexistent' is first in the
> > l3 loop, I see that this bug is not present with MSVC.
> > 
> > I should upgrade to gcc 3.4 or 4 and see if the problem goes away...
> 
> It didn't go away with gcc 3.4.4 so it looks like something
> different. I posted this bugreport on the cygwin list:
> 
> http://sourceware.org/ml/cygwin/2005-09/msg00471.html

It is indeed something different, it's a libtool bug. Here's a
patch for stresstest.at that makes the test pass on Cygwin (and
probably MinGW). I don't think it should be applied, but it shows
where the problem is...

In short, when you specify the symbols to export with
"-export-symbols foo.sym", the file foo.sym is simply prepended
with an EXPORTS line (if missing) and used as a .def input file
for the linker. But when a .def file is specified, the auto-export
magic is shorted out of the loop and the .def file is trusted
blindly. So, the correct fix is that when the symfile given to
libtool does not start with an EXPORTS line, the symbols in it has
to be filtered and " DATA" should be appended to those symbols
that are data symbols, probably similar to what is done when the
-export-symbols-regex option is used.

Cheers,
Peter

Attachment: head-stresstest-cygwin.patch
Description: head-stresstest-cygwin.patch


reply via email to

[Prev in Thread] Current Thread [Next in Thread]