Mail Archives: cygwin-developers/2002/05/25/23:33:02
> -----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
- Raw text -