This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: Q: how to "wrap" malloc()
- To: "Andrew Morton" <morton at nortelnetworks dot com>
- Subject: Re: Q: how to "wrap" malloc()
- From: Andreas Jaeger <aj at suse dot de>
- Date: 24 Oct 1999 17:35:26 +0200
- Cc: "glibc-linux at ricardo dot ecn dot wfu dot edu" <glibc-linux at ricardo dot ecn dot wfu dot edu>
- References: <38131B83.3DD21918@asiapacificm01.nt.com>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
>>>>> Andrew Morton writes:
> A little help, please:
> I wish to intercept calls to malloc(), free(), etc. After doing some
> processing I wish to then call the standard versions.
> This is for use in a general purpose memory-use-checker.
> I do not wish to "#define malloc my_malloc".
> I'd rather not use 'ld --wrap' for portability reasons.
> I require that libc's internal calls to malloc() pass through my
> front-ends.
> I have tried dlopening libc.so.6 from within my own malloc(), plucking
> out the symbols with dlsym() and calling those indirectly from within
> the wrappers, but for non-trivial tests, this is getting a segfault
> within "memcpy () from /lib/ld-linux.so.2". I'm thinking this is
> perhaps not the best way.
> Is there a right way to do this?
Why not do it the other way round? Check the manual for "Storage
Allocation Hooks".
Andreas
--
Andreas Jaeger
SuSE Linux Labs aj@suse.de
private aj@arthur.rhein-neckar.de