revenge of CALLOC_STRUCT

[Michael Blumenkrantz]

I've used it at least once too.


Mike

On Fri, 07 Jan 2022 17:20:11 -0800
Kenneth Graunke <kenneth at whitecape.org> wrote:

> I've definitely used the pipe_reference_described debugging code to
> track down some issues when working on iris.
> 
> --Ken
> 
> On Monday, December 27, 2021 4:18:16 PM PST Marek Olšák wrote:
> > I remember that it wasn't unusual on Windows to define malloc, calloc,
> > strdup, and free macros to redirect those calls to custom wrappers. That
> > would eliminate the need to have non-standard names like MALLOC.
> > 
> > There is also the pipe_reference debug code. Is anybody using that?
> > 
> > Marek
> > 
> > On Sun., Dec. 26, 2021, 05:37 Jose Fonseca, <jfonseca at vmware.com> 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/
> > > [2]
> > > 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.
> > >  
> >   
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20220107/55078da3/attachment.sig>