This is the mail archive of the libc-alpha@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: [PATCH v2] malloc: Remove malloc hooks (Bug 23328)


On 07/23/2018 11:59 AM, Joseph Myers wrote:
> On Mon, 23 Jul 2018, Florian Weimer wrote:
> 
>> Should we install libmalloc-extras.so under that name?
>>
>> Or should it be libmalloc-extras.so.0 (soname) without a libmalloc-extras.so
>> symbolic link, to discourage new applications from linking against it, so
>> making it more obvious that this is intended for backwards compatibility with
>> old applications?
> 
> I don't think it's something to discourage applications from linking 
> against.  Among other things, it's for any use of mtrace, which is useful 
> for both new and old applications as a light-weight memory checker for 
> uses similar to those in glibc's own testsuite.

Let me be clear here.

While I like Joseph's idea that we may wish to deploy libmalloc-extras.so as
something to aspire to that we can provide as an implementation with it's own
ABI, it is *not* what I think we should deploy for 2.28.

Right now for 2.28 I think we should deploy, as Florian suggests, a
libmalloc-extras.so.0, with no so symlink. This DSO is truly for interposition
only. New and old applications can use LD_PRELOAD for now.

Until we have more experience with libmalloc-extras.so I do *not* want to provide
ABI guarantees around this object. It has been designed and tested purely as an
interposer.

Can we agree on this first step?

I'm not opposed to following up in 2.29 with a clear discussion of exactly what
ABI we would provide for libmalloc-extras.so.

Cheers,
Carlos.


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