[cfe-dev] [llvm-dev] Is it really valid to discard externally instantiated functions from a TU when marked inline?

[Dean Michael Berris via cfe-dev]

> On 20 Jul 2018, at 01:49, James Y Knight via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> 
> I haven't looked at what libfuzzer does, but as you've described it, I'd say this _doesn't_ seem a reasonable use-case. If you want to link libc++ (or any other library!) hidden inside your library, you should be using a version-script to only expose symbols that you intend to expose.
> 

In XRay, we go out of our way to not use any standard-library defined symbols that need linkage. We have a tests which ensure that we are able to link the XRay runtime without the standard library dependency. This has been discussed before, I think, precisely in this context.

The options for libFuzzer might be more limited since it’s a special use-case, and I’m sure unless the fuzzer runtime removes dependencies on standard library symbols that libc++ shouldn’t be prioritising this use-case. Another way of saying this is that the cost of ensuring that libFuzzer continues to work despite changes to libc++ should be borne by libFuzzer, not the other way around.

I don’t know how much work is required to use a work-around as James describes with symbol visibility or “privatising” the symbols libFuzzer uses from libc++. It could be less than trying to remove the dependency on libc++ instead.

-- Dean