[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