[Mesa-dev] RFC: Memory allocation on Mesa

Timur Kristóf timur.kristof at gmail.com
Tue May 12 08:36:40 UTC 2020


On Mon, 2020-05-11 at 20:19 +0000, Tamminen, Eero T wrote:
> Hi,
> 
> On Mon, 2020-05-11 at 16:13 +0000, Jose Fonseca wrote:
> > Some might retort: why not just play some tricks with the linker,
> > and
> > intercept all malloc/free calls, without actually having to modify
> > any source code?
> > 
> > Yes, that's indeed technically feasible.  And is precisely the sort
> > of trick I was planing to resort to satisfy VMware needs without
> > having to further modify the source code.  But for these tricks to
> > work, it is absolutely imperative that one statically links C++
> > library and STL.  The problem being that if one doesn't then
> > there's
> > an imbalance: the malloc/free/new/delete calls done in inline code
> > on
> > C++ headers will be intercepted, where as malloc/free/new/delete
> > calls done in code from the shared object which is not inlined will
> > not, causing havoc.  This is OK for us VMware (we do it already for
> > many other reasons, including avoiding DLL hell.)  But I doubt it
> > will be palatable for everybody else, particularly Linux distros,
> > to
> > have everything statically linked.
> 
> Huh?
> 
> I've done a lot of resource usage analysis at former job[1], but I've
> never had needed anything like that.  malloc etc all reside in a
> separate shared library from Mesa, so calls to them always cross
> dynamic library boundary and therefore all of them can be caught with
> the dynamic linker features (LD_PRELOAD, LD_AUDIT...).

I think he meant something like GCC's --wrap option, and wasn't talking
about the dynamic linker.



More information about the mesa-dev mailing list