Breaking the crt1.o -> atexit() -> malloc() dependency
peterjeremy at optushome.com.au
Thu Mar 6 02:06:23 PST 2008
On Thu, Mar 06, 2008 at 11:48:10AM +0200, Kostik Belousov wrote:
>On Wed, Mar 05, 2008 at 05:12:32PM -0800, Tim Kientzle wrote:
>> Here's a design that I think addresses all of the
>> issues people raised, including the POSIX requirement
>> that atexit() always be able to support 32 registrations.
>> It does it without using sbrk() or mmap(), either.
Looks good to me.
>I mostly agree with proposal, but there is also __cxa_atexit().
This is a special variant of atexit() and (as far as I can see)
can be treated in much the same way - allocate struct atexit_fn
and call atexit_register().
>And, besides the issue of the size of the static linked executables,
>there is more exposed problem of atexit() memory leaks. See
I believe that Tim's approach of maintaining a free list and checking
it on each atexit() call would handle this since the dlopen() will
implicitly invoke atexit() or equivalent.
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080306/15269448/attachment.pgp
More information about the freebsd-current