Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: bug in dll_crt0_1()?
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Date: Sun, 26 May 2002 13:33:00 +1000
Message-ID: <FC169E059D1A0442A04C40F86D9BA7600C6161@itdomain003.itdomain.net.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g4Q3X2320440



> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com] 
> Sent: Saturday, May 25, 2002 10:48 AM
> To: cygwin-developers AT cygwin DOT com
> Subject: Re: bug in dll_crt0_1()?
> 
> 
> On Fri, May 24, 2002 at 11:51:36AM +1000, Robert Collins wrote:
> >Interesting situation:
> >
> >I have a function that is called from dll_crt0_1 via
> >  do_global_ctors (&__CTOR_LIST__, 1);
> >that uses malloc(). Malloc is not ready until malloc_init, 
> called from
> >heap_init() called from memory_init(), called from ... dll_crt0_1.
> >
> >Should the memory_init() occur earlier, or should the global 
> >constructor call memory_init() directly? or should malloc() 
> check that 
> >memory_init() has been called?
> 
> Adding malloc calls to cygwin's startup code is something 
> that should be given a lot of thought.  Ditto, adding ctors.  
> If you're profiling cygwin, I think you'll find that a 
> surprising amount of time is taken up in ctors.

It's a catch 22. One can't profile until the arc storage areas is
allocated. That can't be allocated until dll_crt0_1 has run - and
dll_crt0_1 is what calls the constructors. I'm considering ripping out
the current C mcount and gmon implementation for something a little more
dynamic. (I'm also having some terrible issues with _mcount getting the
2nd level caller wrong from the stack, and the current mcount
implementation simply segv's when that occurs. I'd be happy enough
recording the incorrect data and throwing it away at post-analysis for
now.)

Rob