add instrumented `libc++` to `apt.llvm.org` packages

[firewave]

To be able to use MemorySanitizer with C++ it requires an "instrumented libc++" (see https://clang.llvm.org/docs/MemorySanitizer.html#handling-external-code). Unfortunately it seems is is not documented how to build and use that. I came across some repositories which provided (mostly outdated) scripts and Dockerfiles. Not being very familiar with LLVM internals I don't know how well a self-built libraries works if the code doesn't match with the underlying system. But I digress.

There also appears no way to get such a pre-built library. I would have expected some docker images or maybe even a GitHub action but not luck. OSS-Fuzz utilizes it but I have not looked into that so far.

So I am wondering if it were possible to add this as an additional package to the apt.llvm.org packages.

[LebedevRI]

It is documented at least here: https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo

[firewave]

It is documented at least here: https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo

Thanks. I actually visited that side but I only went for the docker references at the end. 🙈

Would be good to link that from the Clang documentation though.

[philnik777]

Would be good to link that from the Clang documentation though.

I don't think we want to link to documentation that's outside the control of the LLVM community.

So I am wondering if it were possible to add this as an additional package to the apt.llvm.org packages.

The problem is that there is no way to switch between sanitized and non-sanitized currently. I think the current plan to make it work more seamlessly is to have instrumented libc++ delivered with clang, which is automatically used when using -fsanitize={memory,address,...}.

[firewave]

I don't think we want to link to documentation that's outside the control of the LLVM community.

Actually it is already linked at the end of that page - and that page links to the other one. Sorry about that - again. But a good part of the actual documentation already lives in that external repo.

The problem is that there is no way to switch between sanitized and non-sanitized currently.

If the instrumented one is available you could have explicitly specified it during linking like shown on that page which describes how to use it. I am not sure if you would actually want to switch it.

I think the current plan to make it work more seamlessly is to have instrumented libc++ delivered with clang, which is automatically used when using -fsanitize={memory,address,...}.

That sounds way better. Looking forward to it.

[firewave]

I just realized the title is quite misleading.

I was thinking of adding an * additional* package with the instrumented library (i.e. libcxx-msan) instead of adding it to existing ones. That might not change things but I wanted to clarify my intent.

[sylvestre]

what would you like to see?
Something like
libc++-15-dev-masm ?

[firewave]

Sorry for the late reply.

what would you like to see? Something like libc++-15-dev-masm ?

Maybe. I have no idea how it would even be possible to use it so it would require having the library beside the instrumentation one (replacing it for the whole system would obviously wreck a lot of havoc).

There's a draft PR (#72688) which aims to introduce different named libraries for the various instrumented/sanitized ones. Maybe an approach on how to implement this in terms of packaging comes out of that work.

[ldionne]

I don't think this is something we want to solve at the packaging level. I'm not 100% certain yet, but I think it makes more sense for the libc++ package to contain all the variants of libc++ that we claim to support w.r.t. sanitizers. That way, everything will work out of the box with libc++ and Clang, no need to install different packages on the side.