This is the mail archive of the 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]


On 2/15/19 9:50 AM, Vincent Whitchurch wrote:
> On Fri, Feb 15, 2019 at 12:43:54PM +0100, Florian Weimer wrote:
>> * Vincent Whitchurch:
>>> Currently, DSOs preloaded with LD_PRELOAD are initialized after
>>> linked-in DSOs, unless dependencies require otherwise.
>>> However, in some cases it is desirable that preloaded DSO are
>>> initialized before linked-in DSOs (unless dependencies require
>>> otherwise).  For example, when malloc is overloaded using a preloaded
>>> DSO for the purpose of heap profiling, we ideally want the preloaded DSO
>>> to be initialized before other DSOs so that it has a chance to set up
>>> its accounting code before their initializers are called.
>>> Changing the default behaviour could lead to breakage, so add a new
>>> environment variable, LD_PRELOAD_INIT_EARLY, the presence of which will
>>> ask preloaded libraries to be initialized as early as possible and
>>> finalized as late as possible.  If multiple DSOs are preloaded, DSOs
>>> earlier on the LD_PRELOAD list will be initalized earlier and finalized
>>> later than DSOs present later on the list.
>>> Note that dependencies are still taken into account: DSOs which the
>>> preloaded DSO depends on are correctly initalized before it and
>>> finalized after it.
>> Maybe we should LD_PRELOAD to use this behavior instead?  Isn't that
>> what users expect?
> It's certainly what I personally expect, but I feared that someone may
> actually be depending on the current behaviour, hence the new variable.
> But I can certainly just change LD_PRELOAD's default behaviour if you
> think that there is no risk for that.
The order of initializers is not guaranteed unless there are explicit
dependencies. I would rather see what you describe becomes the *default*
behviour for LD_PRELOAD, and we should try to add a section in the manual
to describe this so we have documented the new behaviour.

Let me post the new manual text which is Ben Woodard's work and get that
in place first and then we can add to it.


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