www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/09/01/10:38:31

From: khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject: [patch] Re: global constructor using iostreams fail
1 Sep 1998 10:38:31 -0700 :
Message-ID: <Pine.SUN.3.93.980901111351.5509B-200000.cygnus.cygwin32.developers@modi.xraylith.wisc.edu>
References: <19980901093344 DOT B16818 AT cygnus DOT com>
Reply-To: Mumit Khan <khan AT xraylith DOT wisc DOT edu>
Mime-Version: 1.0
To: Christopher Faylor <cgf AT cygnus DOT com>
Cc: cygwin32-developers AT cygnus DOT com

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime AT docserver DOT cac DOT washington DOT edu for more info.

--1915750185-2096489607-904669424=:5590
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 1 Sep 1998, Christopher Faylor wrote:

> Is this using a coolview version of a b19 version?

Release, Coolview and Geoffrey's snapshots. The bug has always been
there.

> 
> This should be handled when global constructors are run, right?
> Would this be for the global constructors of the .dll or the
> user code?

The trouble is the incorrect ordering of the global constructors, and
instead of the iostreams constructors getting called first, the user
global constructor is getting called in __do_global_constructors 
and we get the crash. Here's a stack dump:

  #0  global constructors keyed to foo1 () at foo.cc:9
  #1  0x100053fa in __do_global_ctors () at ../../../winsup/dcrt0.cc:746
  #2  0x10005433 in __main () at ../../../winsup/dcrt0.cc:758
  #3  0x401084 in main () at foo.cc:18
  #4  0x100052d0 in dll_crt0_1 (uptr=0x418018) at ../../../winsup/dcrt0.cc:694
  #5  0x1000533d in dll_crt0 (uptr=0x418018) at ../../../winsup/dcrt0.cc:715
  #6  0x417361 in cygwin_crt0 (f=0x40107c <main>)
      at ../../../winsup/libccrt0.cc:99

Note that #0 shows the *first* global constructor, but it should *NOT* be. 
Now let's take a look at the global constructor list, pfunc, in 
dcrt0.cc:__do_global_ctors():

  (gdb) print pfunc[0]@5
  print pfunc[0]@5
  $10 = {0xffffffff, 0x4010b8 <global constructors keyed to foo1>, 
    0x40230c <global constructors keyed to ios::tie(void) const>, 
    0x407598 <global constructors keyed to _IO_stdin_>, 0}
  (gdb) 

Now you see the problem!

So, why is this happening?? It's in __do_global_ctors, which calls the 
functions pointers registered in __CTOR_LIST__ in the incorrect order.
Ditto for __do_global_dtors. I'm attaching a patch.

Those in doubt of the order should see gcc/libgcc2.c and gcc/gbl-ctors.h
for further info. One of those reasons it's best to use these functions
from libgcc.a instead of having local copies in winsup.

Regards,
Mumit


--1915750185-2096489607-904669424=:5590
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="c++gbl.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine DOT SUN DOT 3 DOT 93 DOT 980901120344 DOT 5590B AT modi DOT xraylith DOT wisc DOT edu>
Content-Description: Global constr/destr fix

VHVlIFNlcCAgMSAxMTo0MToyNCAxOTk4ICBNdW1pdCBLaGFuICA8a2hhbkB4
cmF5bGl0aC53aXNjLmVkdT4NCg0KCSogZGNydDAuY2MgKGRsbF9jcnQwKTog
Rml4IG9yZGVyaW5nIG9mIGdsb2JhbCBjb25zdHJ1Y3RvcnMuDQoJKF9fZG9f
Z2xvYmFsX2N0b3JzKTogTGlrZXdpc2UuDQoJKF9fZG9fZ2xvYmFsX2R0b3Jz
KTogRml4IG9yZGVyaW5nIG9mIGdsb2JhbCBkZXN0cnVjdG9ycy4NCg0KSW5k
ZXg6IGRjcnQwLmNjDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmls
ZTogL21vdW50cy9zZGE3L3NyYy9nbnUvQ1ZTUk9PVC9jeWd3aW4zMi93aW5z
dXAvZGNydDAuY2Msdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjEuMS4xDQpk
aWZmIC11IC0zIC1wIC1yMS4xLjEuMSBkY3J0MC5jYw0KLS0tIGRjcnQwLmNj
CTE5OTgvMDgvMzAgMDM6NDY6NDMJMS4xLjEuMQ0KKysrIGRjcnQwLmNjCTE5
OTgvMDkvMDEgMTY6Mzg6MzENCkBAIC03MDcsNyArNzA3LDEyIEBAIGRsbF9j
cnQwIChwZXJfcHJvY2VzcyAqdXB0cikNCiAgIGludCBpOw0KICAgdm9pZCAo
KipwZnVuYykoKSA9ICZfX0NUT1JfTElTVF9fOw0KIA0KKyAgLyogUnVuIGN0
b3JzIGJhY2t3YXJkcywgc28gc2tpcCB0aGUgZmlyc3QgZW50cnkgYW5kIGZp
bmQgaG93IG1hbnkNCisgICAgIHRoZXJlIGFyZSwgdGhlbiBydW4gdGhlbS4g
Ki8NCisNCiAgIGZvciAoaSA9IDE7IHBmdW5jW2ldOyBpKyspDQorICAgIDsN
CisgIGZvciAoaSA9IGkgLSAxOyBpID4gMDsgaS0tKQ0KICAgICB7DQogICAg
ICAgKHBmdW5jW2ldKSAoKTsNCiAgICAgfQ0KQEAgLTcyMSwxNyArNzI2LDkg
QEAgX19kb19nbG9iYWxfZHRvcnMgKHZvaWQpDQogICBpbnQgaTsNCiAgIHZv
aWQgKCoqcGZ1bmMpKCkgPSB1c2VyX2RhdGEtPmR0b3JzOw0KIA0KLSAgLyog
UnVuIGR0b3JzIGJhY2t3YXJkcywgc28gc2tpcCB0aGUgZmlyc3QgZW50cnkg
YW5kIGZpbmQgaG93IG1hbnkNCi0gICAgIHRoZXJlIGFyZSwgdGhlbiBydW4g
dGhlbS4gKi8NCi0NCi0gIGlmIChwZnVuYykNCisgIGZvciAoaSA9IDE7IHBm
dW5jW2ldOyBpKyspDQogICAgIHsNCi0gICAgICBmb3IgKGkgPSAxOyBwZnVu
Y1tpXTsgaSsrKQ0KLQk7DQotICAgICAgZm9yIChpID0gaSAtIDE7IGkgPiAw
OyBpLS0pDQotCXsNCi0JICAocGZ1bmNbaV0pICgpOw0KLQl9DQorICAgICAg
KHBmdW5jW2ldKSAoKTsNCiAgICAgfQ0KIH0NCiANCkBAIC03NDEsNyArNzM4
LDEyIEBAIF9fZG9fZ2xvYmFsX2N0b3JzICh2b2lkKQ0KICAgaW50IGk7DQog
ICB2b2lkICgqKnBmdW5jKSgpID0gdXNlcl9kYXRhLT5jdG9yczsNCiANCisg
IC8qIFJ1biBjdG9ycyBiYWNrd2FyZHMsIHNvIHNraXAgdGhlIGZpcnN0IGVu
dHJ5IGFuZCBmaW5kIGhvdyBtYW55DQorICAgICB0aGVyZSBhcmUsIHRoZW4g
cnVuIHRoZW0uICovDQorDQogICBmb3IgKGkgPSAxOyBwZnVuY1tpXTsgaSsr
KQ0KKyAgICA7DQorICBmb3IgKGkgPSBpIC0gMTsgaSA+IDA7IGktLSkNCiAg
ICAgew0KICAgICAgIChwZnVuY1tpXSkgKCk7DQogICAgIH0NCg==
--1915750185-2096489607-904669424=:5590--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019