Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[James R. Phillips]

Does fixing this bug require upstream intervention, or can you just develop a
patch, and submit it to upstream?

Anecdotal evidence [1] exists that this issue may be what prevents compiling a
working version of octave 2.1.71 with gcc 3.4.4.  This comes from John Ewing
(octave upstream), who states that he is able to compile a working version with
gcc 3.4.4 only if it is statically linked.

John also wonders [2] why libstdc++ is static as opposed to shared on cygwin. 
I have searched the archives, and verified its static nature, but was unable to
find an explanation.

[1] http://www.octave.org/mailing-lists/help-octave/2005/3734
[2] http://www.octave.org/mailing-lists/help-octave/2005/3738

jrp


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Charles Wilson]

James R. Phillips wrote:
> John also wonders [2] why libstdc++ is static as opposed to shared on cygwin. 
> I have searched the archives, and verified its static nature, but was unable to
> find an explanation.
> 
> [1] http://www.octave.org/mailing-lists/help-octave/2005/3734
> [2] http://www.octave.org/mailing-lists/help-octave/2005/3738

IIRC this is what mathematicians call a "hard problem". :-)

gcc is fully autotoolized: it uses autoconf, automake, and libtool when 
building.  However, you really only get decent cygwin support for DLLs 
from libtool of 1.5.x series or better.  BUT, this requires at least 
automake-1.7.x or better, which in turn requires autoconf-2.5x or better.

Until "recently" (circa last 18 months or so), gcc used MUCH older 
versions of these tools: autoconf-2.13, automake???, and (worst of all) 
a privately hacked version of libtool-1.4.x.  However, over the last 
year or more, several dedicated people have been slowly moving gcc's 
build system over to more modern autotools.

I do not know if that process is complete, but it is a necessary (but 
not sufficient) step for building the runtime libraries as DLLs under 
cygwin.  There has been sporadic interest in correcting this problem, 
and convincing gcc to build dll runtimes under cygwin, but:
  (1) as I said, this is a "hard" problem
  (2) and it hasn't been very pressing issue: C doesn't have this 
problem; only C++, Fortran, (maybe others) need additional runtime libs 
other than cygwin1.dll -- and C is the 800 lb gorilla of open source 
software.  C++, Fortran, etc, are often afterthoughts unfortunately 
(except in specialized fields like hardcore numerics).

FWIW, Nicholas Wourms has expresses recent interest on this list in 
trying to resolve this issue (and IIRC he was active with the gcc team 
~18 months ago, and has just recently 'returned').  Nick?

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Pavel Tsekov]

On Tue, 4 Oct 2005, James R. Phillips wrote:

> Does fixing this bug require upstream intervention, or can you just develop a
> patch, and submit it to upstream?

If it is only the std::string implementation that uses the described
optimization the problem can be worked around by just rebuilding libstdc++
with _GLIBCXX_FULLY_DYNAMIC_STRING defined. If other classes provided by
libstdc++ use similiar techniques the best solution would be to get
libstdc++ built as shared library which according to Charles Wilson is
unfortunately a "hard problem" :(

I'll try to rebuild libstdc++ now with _GLIBCXX_FULLY_DYNAMIC_STRING
defined and will report back if there is interest. I would like to help
to get this issue resolved.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Gerrit P. Haase]

James R. Phillips wrote:

> Does fixing this bug require upstream intervention, or can you just develop a
> patch, and submit it to upstream?

A patch would be nice!


> Anecdotal evidence [1] exists that this issue may be what prevents compiling a
> working version of octave 2.1.71 with gcc 3.4.4.  This comes from John Ewing
> (octave upstream), who states that he is able to compile a working version with
> gcc 3.4.4 only if it is statically linked.
> 
> John also wonders [2] why libstdc++ is static as opposed to shared on cygwin. 
> I have searched the archives, and verified its static nature, but was unable to
> find an explanation.
> 
> [1] http://www.octave.org/mailing-lists/help-octave/2005/3734
> [2] http://www.octave.org/mailing-lists/help-octave/2005/3738

As long as GCC does not support recent libtool versions it is not easy
to build dynamic libraries.


Gerrit
-- 
=^..^=

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Gerrit P. Haase]

Pavel Tsekov wrote:

> On Tue, 4 Oct 2005, James R. Phillips wrote:
> 
> 
>>Does fixing this bug require upstream intervention, or can you just develop a
>>patch, and submit it to upstream?
> 
> 
> If it is only the std::string implementation that uses the described
> optimization the problem can be worked around by just rebuilding libstdc++
> with _GLIBCXX_FULLY_DYNAMIC_STRING defined. If other classes provided by
> libstdc++ use similiar techniques the best solution would be to get
> libstdc++ built as shared library which according to Charles Wilson is
> unfortunately a "hard problem" :(
> 
> I'll try to rebuild libstdc++ now with _GLIBCXX_FULLY_DYNAMIC_STRING
> defined and will report back if there is interest. I would like to help
> to get this issue resolved.

Yes, much appreciated.  Please CC me when you report back!

Gerrit
-- 
=^..^=

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Pavel Tsekov]

On Wed, 5 Oct 2005, Gerrit P. Haase wrote:

> Pavel Tsekov wrote:
>
> > I'll try to rebuild libstdc++ now with _GLIBCXX_FULLY_DYNAMIC_STRING
> > defined and will report back if there is interest. I would like to help
> > to get this issue resolved.
>
> Yes, much appreciated.  Please CC me when you report back!

I rebuilt libstdc++ with --enable-fully-dynamic-string and preliminary
testing showed that both the testcase and the program that I am porting
behave fine. I'll do more testing in the next few days. I haven't done any
benchmarks so far. Any suggestions/ideas on how to test whether the speed
has decreased due to --enable-fully-dynamic-string ?

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Gerrit P. Haase]

Pavel Tsekov wrote:

> On Wed, 5 Oct 2005, Gerrit P. Haase wrote:
> 
> 
>>Pavel Tsekov wrote:
>>
>>
>>>I'll try to rebuild libstdc++ now with _GLIBCXX_FULLY_DYNAMIC_STRING
>>>defined and will report back if there is interest. I would like to help
>>>to get this issue resolved.
>>
>>Yes, much appreciated.  Please CC me when you report back!
> 
> 
> I rebuilt libstdc++ with --enable-fully-dynamic-string and preliminary
> testing showed that both the testcase and the program that I am porting
> behave fine. I'll do more testing in the next few days. I haven't done any
> benchmarks so far. Any suggestions/ideas on how to test whether the speed
> has decreased due to --enable-fully-dynamic-string ?

Maybe you find some more hints at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612

I will probably use the flag to rebuild gcc with this changed libstdc++,
regardless if there is a performance issue or not.


Gerrit
-- 
=^..^=

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Pavel Tsekov]

On Thu, 6 Oct 2005, Gerrit P. Haase wrote:

> I will probably use the flag to rebuild gcc with this changed libstdc++,
> regardless if there is a performance issue or not.

What about Danny Smith's suggestion ?

http://www.cygwin.com/ml/cygwin/2005-10/msg00080.html


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Yaakov S (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerrit P. Haase wrote:
> As long as GCC does not support recent libtool versions it is not easy
> to build dynamic libraries.

What about just replacing the autogenerated libtool script with a newer
one (manually hacked if necessary for options) after configure?  GNOME
1.4 has similar problems, and that's how I've managed to work around it;
but then again building gcc is *much* more complicated.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDRZQzpiWmPGlmQSMRAikvAJwKVd/qmNvhIEftgey8rsdXGKfXMACg/TpB
JFfJFTN6F4lq+D+qrVHR4ts=
=B0cn
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Gerrit P. Haase]

Yaakov S (Cygwin Ports) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Gerrit P. Haase wrote:
> 
>>As long as GCC does not support recent libtool versions it is not easy
>>to build dynamic libraries.
> 
> 
> What about just replacing the autogenerated libtool script with a newer
> one (manually hacked if necessary for options) after configure?  GNOME
> 1.4 has similar problems, and that's how I've managed to work around it;
> but then again building gcc is *much* more complicated.

Unfortunately this doesn't work very good with GCC.


Gerrit
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Gerrit P. Haase]

Pavel Tsekov wrote:

> Can we get this fixed ?

I entered a bugreport:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196


Gerrit
-- 
=^..^=

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

ATTN: g++ maintainer: Using string instances to pass arguments to dlls

[Pavel Tsekov]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3428 bytes --]

Hello,

I noticed the following problem while porting an internal C++ application
from linux to Cygwin. If a std::string instance created in one module
(exe or dll) is passed to another say as an argument of a function call,
the program crashes or hangs. I did debug for a while and it turned
out that it is not the program itself that causes the crash - the cause
lies in the std::string implementation, the fact that libstdc++ is
provided as a static archive and that it is compiled without
_GLIBCXX_FULLY_DYNAMIC_STRING defined.

What happens is that each module which links agains libstdc++ get its very
personal copy of the class member _S_empty_rep_storage. Now since
_GLIBCXX_FULLY_DYNAMIC_STRING is not defined an empty string instance i.e.
one that is created by the default constructor of std::string gets a
pointer to _S_empty_rep_storage i.e. the actual allocation of memory is
delayed until memory is really needed. If _GLIBCXX_FULLY_DYNAMIC_STRING is
defined each string instance would get a pointer to a newly heap
allocated block of memory instead . Now look at the ouput of gdb and nm
used on the attached testcase:

Administrator@mordor ~/src/testcase/tc
$ nm dll.dll | grep _S_empty_rep_storage
1000c030 d .data$_ZNSs4_Rep20_S_empty_rep_storageE
1000c030 D __ZNSs4_Rep20_S_empty_rep_storageE

Administrator@mordor ~/src/testcase/tc
$ nm main.exe | grep _S_empty_rep_storage
00442120 d .data$_ZNSs4_Rep20_S_empty_rep_storageE
00442120 D __ZNSs4_Rep20_S_empty_rep_storageE

===
Breakpoint 1, main (argc=1, argv=0x10042980) at main.cc:9
9       {
(gdb) n
10        string s, s1;
(gdb)
12        export1 (s);
(gdb) print s
$1 = {static npos = 4294967295, _M_dataplus = {<allocator<char>> =
{<new_allocator<char>> = {<No data fields>}, <No data fields>},
    _M_p = 0x44212c ""}}
(gdb) print s1
$2 = {static npos = 4294967295, _M_dataplus = {<allocator<char>> =
{<new_allocator<char>> = {<No data fields>}, <No data fields>},
    _M_p = 0x44212c ""}}
===

Here the two strings share _S_empty_rep_storage.

===
(gdb) step
export1 (s=@0x22eea0) at dll.cc:7
7         string s1;
(gdb) n
9         s1.push_back ('A');
(gdb) n
10        s.push_back ('A');
(gdb) print s
$3 = (string &) @0x22eea0: {static npos = 4294967295,
  _M_dataplus = {<allocator<char>> = {<new_allocator<char>> = {<No data
fields>}, <No data fields>}, _M_p = 0x44212c ""}}
(gdb) print s1
$4 = {static npos = 4294967295, _M_dataplus = {<allocator<char>> =
{<new_allocator<char>> = {<No data fields>}, <No data fields>},
    _M_p = 0x10042aec "A"}}
(gdb)
===

Here s1 points to the dll local _S_empty_rep_storage.

The _M_p member of _M_dataplus is pointing to different copies of
_S_empty_rep_storage - one stored in the executable which calls the dll
and another one in the dll itself.

Now the second push_back() call in export1 () will end up calling
_M_mutate() to actually allocate storage. _M_mutate() will call
_M_rep()->_M_dispose() which will end up free()-ing the memory reserved
for _S_empty_rep_storage in the main exe. There is a check to prevent free()-ing
_S_empty_rep_storage:

#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
          if (__builtin_expect(this != &_S_empty_rep(), false))
#endif

... but it doesn't work well in the case when a string instance created
in one module is passed to another and libstdc++ is statically linked
because of the fact that each module has its own copy
_S_empty_rep_storage.

Can we get this fixed ?

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 423 bytes --]

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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/