On Fri, 2010-02-19 at 10:23 -0800, Kristian Høgsberg wrote: > 2010/2/19 Brian Paul <brian.e.p...@gmail.com>: > > 2010/2/19 Kristian Høgsberg <k...@bitplanet.net>: > >> 2010/2/19 Kristian Høgsberg <k...@bitplanet.net>: > >>> 2010/2/19 Brian Paul <brian.e.p...@gmail.com>: > >>>> 2010/2/19 Kristian Høgsberg <k...@bitplanet.net>: > >>>> > >>>>> I applied the patches from Kenneth Graunke on the list for this. Can > >>>>> we drop _mesa_malloc(), _mesa_calloc() and _mesa_free() and > >>>>> _mesa_bzero() too? > >>>> > >>>> I've remove _mesa_bzero() just now, plus some other macro wrappers. > >>>> > >>>> We might as well remove the malloc/calloc() wrappers too, but that'll > >>>> be a bit more work. > >>> > >>> I'm using: > >>> > >>> git grep -l _mesa_malloc | xargs sed -ie s/_mesa_malloc/malloc/g > >>> > >>> which does most of the work. I'll do the same thing for _mesa_calloc > >>> and _mesa_free, review the result and commit that. > >> > >> All done. I was looking at the MALLOC, CALLOC, MALLOC_STRUCT, > >> CALLOC_STRUCT, and FREE macros and the ALIGN_* macros for the > >> _mesa_align_* functions. Do we want to drop those too? I hesitated > >> because src/gallium/README.portability says "Use MALLOC, CALLOC, FREE > >> instead of the malloc, calloc, free functions." But as far as I can > >> see, they're not redefined or anything for gallium and they just > >> resolve to the standard malloc, calloc and free functions. Am I > >> missing something? > > > > Let's keep the Gallium code as-is. > > > > But for Mesa: > > > > MALLOC_STRUCT and CALLOC_STRUCT should be kept. They save a lot of typing. > > > > MALLOC, CALLOC, and FREE can go. The ALIGN macros could probably go > > too (just call the align functions). > > > > Years ago, some systems defined malloc() as returning char * instead > > of void * so the Mesa wrappers helped with casting. Plus, back before > > valgrind I'd often rig up my own malloc-debug code to track down > > memory errors. The macros were handy for that. > > Ok, I droppped the ALIGN macros, but I'll leave the rest as is. Not > sure what Jose has in mind, but I hope we can drop the MALLOC, CALLOC > and FREE wrappers as well. At least on Linux today, we have valgrind > and LD_PRELOAD tricks available to do malloc debugging that doesn't > require malloc wrappers.
My plan was to use pretty much the src/gallium/auxiliary/os/os_memory.h as is. Mesa will never run in kernel mode like gallium needs to, but it still quite cross-platform, so having a thing abstraction on top of STDC free/malloc/calloc is always a convenient. Linux has very nice memory debugging tools indeed, but windows has nothing near valgrind. Even if one is willing to pay. Also the debugging wrappers are convenient because they run every time -- if you introduce a regression you quickly see that in the final report when closing the app. It's not necessary to go out of the way to run a debugging tool. Jose ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
