[PATCH v2 3/6] malloc: Basic support for memory tagging in the malloc() family

[DJ Delorie]

Richard Earnshaw <Richard.Earnshaw@foss.arm.com> writes:
>> Do we need to mangle/demangle these pointers?  I don't see them as
>> anything but internally stored pointers, so maybe no, but if those
>> static pointers could be corrupted, yes?
>
> I just followed the model used for __morecore.  That wasn't mangled,
> AFAICT, so I think these only need mangling if that does.

Ok.

>> Note that there's another patch set by Carlos and I to move all the
>> hook-related stuff out of libc.so and into libmtrace.so.
>
> I can't find those patches (at least, searching for libmtrace only shows
> your reply on this thread).

Starts here...
https://sourceware.org/legacy-ml/libc-alpha/2018-04/msg00131.html

It's still on our plate to finish this work, though.

>> This is duplicating the request2size() macro's purpose, and is only used
>> when request2size is used anyway, so this logic should be within
>> request2size.  request2size() is used in more places than
>> checked_request2size.
>
> There's a problem with that.  request2size() has to be evaluated
> statically at compile time, as it's used to size some arrays; so it
> can't access __mtag_granule_mask as that's not statically constant.

Ah, ok.  Comments to that effect then, please :-)

And please review the other cases of request2size() to see if they need
to be amended as well.

>> Ok.  There should be a section in the manual (manual/*) about tagging,
>> with a list of performance (speed/size) impacts such as these.
>
> Until I have real hardware, and have fully optimized the back-end
> operations, I'm not sure what the overall impact is going to be.
> Clearly it won't be zero, as coloring blocks of memory on allocation or
> free'ing is proportional to the size of the object.

I suspect the memory overhead of the PREV_CHUNK word not being usable by
the app, will be the most contentious change here.  Small allocations
are already memory inefficient enough.

>> It's 2020 now :-)
>
>
> Really?  With all this lockdown I think I'd rather go back to 2019 :)

Patching like it's 1999 :-)