<p dir="ltr">On 17 Mar 2013 22:32, "Alexey Samsonov" <<a href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br>
><br>
> +glider<br>
><br>
> Decreasing the binary size is a great goal... I think that dlopen'ing DSOs that weren't linked with is a pretty common scenario, but it's just a guess. Alex, does this happen in Chromium, for example?<br>

> If the workaround for users will be to manually add --export-dynamic to the link command, we should mention it somewhere in the manual.<br>
><br>
> On Sat, Mar 16, 2013 at 5:35 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> When linking a sanitizer runtime, we add -export-dynamic to the link lines. This can *dramatically* increase binary sizes (I've seen a 25% increase in some cases), and seems to be largely unnecessary -- the sanitizer symbols should be exported anyway if the linker is told about any DSOs which need the runtime and will be linked against the binary.<br>

>><br>
>> However, this will presumably break any mostly-static binaries which don't link against any sanitizer-using DSOs, but do dlopen such DSOs. If we care about that, I think the right way to handle it would be to add a file containing a list of exported sanitizer symbols to compiler-rt, and pass that file to the linker with --dynamic-list when linking in a sanitizer.<br>

><br>
><br>
> Do you plan to generate this list when building compiler-rt and store it next to the runtime in the resource directory?</p>
<p dir="ltr">I was intending to have a manually maintained list, but generating it would be better.</p>
<p dir="ltr">>><br>
>><br>
>> What do you think? Is this patch OK as-is, or do you want the more complete solution?<br>
>><br>
>> Thanks!<br>
>> Richard<br>
><br>
><br>
><br>
><br>
> -- <br>
> Alexey Samsonov, MSK</p>