revenge of CALLOC_STRUCT

[Eero Tamminen]

Hi,

Valgrind should be able to report mismatching alloc & free calls, and I 
think one can also annotate which functions are alloc & free ones.

AFAIK Valgrind does not work on Windows, but you could Valgrind Windows 
Mesa version on Linux using Wine.


	- Eero

On 26.12.2021 12.37, Jose Fonseca wrote:
> I believe that as long as the CALLOC_STRUCT continue to get paired with 
> right FREE call (or equivalent if these get renamed) either way should 
> work for us.  Whatever option proposed gets followed, there's a risk 
> these can get out of balanced, but the risk seems comparable.
> 
> 
> For context, IIRC, the main reason these macros remain useful for VMware 
> is the sad state of memory debugging tools on Windows.  AFAICT, best 
> hope of one day deprecating this would be use AddressSanitizer, which is 
> supported on MSVC [1], but unfortunately not yet on MinGW w/ GCC [2], 
> and we rely upon a lot for day-to-day development, using Linux 
> cross-compilation.  Using MinGW w/ Clang cross compiler seems be a way 
> to overcome this difficulty, but that too was still in somewhat 
> experimental state when I last tried it.
> 
> 
> Jose
> 
> [1] 
> https://devblogs.microsoft.com/cppblog/asan-for-windows-x64-and-debug-build-support/ 
> <https://devblogs.microsoft.com/cppblog/asan-for-windows-x64-and-debug-build-support/>
> [2] 
> https://stackoverflow.com/questions/67619314/cannot-use-fsanitize-address-in-mingw-compiler 
> <https://stackoverflow.com/questions/67619314/cannot-use-fsanitize-address-in-mingw-compiler>
> ------------------------------------------------------------------------
> *From:* Dave Airlie <airlied at gmail.com>
> *Sent:* Wednesday, December 22, 2021 22:35
> *To:* mesa-dev <mesa-dev at lists.freedesktop.org>; Jose Fonseca 
> <jfonseca at vmware.com>; Brian Paul <brianp at vmware.com>
> *Subject:* revenge of CALLOC_STRUCT
> Hey,
> 
> Happy holidays, and as though to consider over the break,
> 
> We have the vmware used MALLOC/FREE/CALLOC/CALLOC_STRUCT wrappers used
> throughout gallium.
> 
> We have ST_CALLOC_STRUCT in use in the mesa state tracker, not used in 
> gallium.
> 
> Merging the state tracker into mesa proper, and even prior to this a
> few CALLOC_STRUCT have started to leak into src/mesa/*.
> 
> Now I don't think we want that, but CALLOC_STRUCT is a genuinely
> useful macro on it's own,
> I'm considering just defined a calloc_struct instead for the
> non-gallium use that goes with malloc/calloc/free.
> 
> Any opinions, or should mesa just get u_memory.h support for Xmas?
> 
> Dave.