Re: -z preinitarray

From: Dan Koren (dankoren_at_yahoo.com)
Date: 04/29/05 

Date: Fri, 29 Apr 2005 15:38:53 -0400

"Seongbae Park" <Seongbae.Park@Sun.COM> wrote in message
news:d4tk3d$svj$1@news1nwk.SFbay.Sun.COM...
> Dan Koren <dankoren@yahoo.com> wrote:
>>
>>
>> I tried moving one of the initialization functions in a
>> shared library to the preinitialization section, using
>> the -z preinitarray ld option, and now it is no longer
>> called!
>>
>> I am wondering what might cause this behavior. According
>> to the linker manual, a function specified in this ld
>> option is moved into the preinitialization section, and
>> if a preinitialization section does not already exist,
>> one would be created.
>>
>> What am I missing? Any advice would be greatly appreciated.
>>
>> Thx,
>>
>>
>> dk
>
> From S10 Linker and Libraries Guide:
>
> A dynamic executable can provide pre-initialization functions in a
> ^^^^^^^^^^
> .preinit_array section. These functions are executed after the runtime
> linker has built the process image and performed relocations but
> before any other initialization functions. Pre-initialization functions
> are
> not permitted in shared objects.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> In short, preinit_array doesn't work in shared object.

OK, thanks.

Does this imply, in effect, that there is no way for an
interposer shared library (e.g. a memory allocator) to
arrange to always initialize itself first, before any
other library or code in the main executable, and
regardless of how the main executable may have
been built?

The paragraph you quoted seems to suggest that if the
main executable's preinitialization section relies on
malloc, an interposer memory allocator library might
not be able to intercept (some of) the calls.

Thx,

dk

Quantcast