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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
