This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: atexit in a glibc function


On Jun 16, 2012, at 1:52 AM, Mike Frysinger wrote:

> On Saturday 16 June 2012 01:05:25 Amittai Aviram wrote:
>> On Jun 16, 2012, at 1:00 AM, Mike Frysinger wrote:
>>> On Saturday 16 June 2012 00:35:27 Amittai Aviram wrote:
>>>> I have been writing a custom variant of glibc Version 2.14 that differs
>>>> primarily in malloc/malloc.c .
>>>> 
>>>> 
>>>> My malloc.c definitely #includes <stdlib.h>.  Why doesn't the linker
>>>> recognize "atexit"?  Thanks!
>>> 
>>> because in the x86-64 port, atexit isn't provided by the C library.  it's
>>> in libc_nonshared.a which means the symbol ends up in the final
>>> application, not in the libc.so.  so you may not use atexit() inside of
>>> the C library.
>> 
>> OK, thanks!  I'll have to work around that then.
> 
> there's __attribute__((destructor))
> 
>>> malloc (and friends) are designed to be overridden at runtime.  create a
>>> shared library that exports those symbols and simply LD_PRELOAD it and
>>> those funcs will be called whenever memory is needed.  why do you need
>>> to rebuild glibc to do what you want ?
>> 
>> That sounds like a good idea.  But--for other reasons--I want to build my
>> applications with static linkage.  Wouldn't the linker notice conflicting
>> definitions of malloc and refuse to continue?  Thanks!
> 
> it's even easier with static archives.  specify your library first and only 
> your malloc objects will get used.
> -mike


You are right--it works great.  Follow-up question:  what do you mean by their being "designed to be overridden at runtime"?  How do they differ from other library functions so that they are specifically designed with this in mind?  Thanks!

Amittai

Amittai Aviram
PhD Student in Computer Science
Yale University
646 483 2639
amittai.aviram@yale.edu
http://www.amittai.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]