On Tue, Mar 19, 2013 at 4:06 AM, Alexey Samsonov <span dir="ltr"><<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div class="h5">On Mon, Mar 18, 2013 at 9:40 AM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br></div></div><div class="gmail_extra">
<div class="gmail_quote"><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><p dir="ltr">On 17 Mar 2013 22:32, "Alexey Samsonov" <<a href="mailto:samsonov@google.com" target="_blank">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" target="_blank">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>
</div></div><p dir="ltr">I was intending to have a manually maintained list, but generating it would be better.</p></blockquote></div></div><div> $ ./bin/llvm-nm lib/clang/3.3/lib/linux/libclang_rt.asan-x86_64.a | grep "T __asan"</div>
<div><div>000017b0 T __asan_get_allocated_size</div><div>00001760 T __asan_get_estimated_allocated_size</div><div>00001770 T __asan_get_ownership</div><div>000009e0 T __asan_stack_free</div><div>00000990 T __asan_stack_malloc</div>
<div>00000780 T __asan_after_dynamic_init</div><div>00000530 T __asan_before_dynamic_init</div><div>00000150 T __asan_register_globals</div><div>00000380 T __asan_unregister_globals</div><div>000006e0 T __asan_address_is_poisoned</div>
<div>000002e0 T __asan_poison_memory_region</div><div>000009e0 T __asan_poison_stack_memory</div><div>00000720 T __asan_region_is_poisoned</div><div>000004f0 T __asan_unpoison_memory_region</div><div>00000b30 T __asan_unpoison_stack_memory</div>
<div>000024f0 T __asan_describe_address</div><div>00001770 T __asan_report_error</div><div>000024b0 T __asan_set_error_report_callback</div><div>000006c0 T __asan_handle_no_return</div><div>00000730 T __asan_init_v2</div>
<div>00000470 T __asan_report_load1</div><div>00000530 T __asan_report_load16</div><div>000004a0 T __asan_report_load2</div><div>000004d0 T __asan_report_load4</div><div>00000500 T __asan_report_load8</div><div>00000650 T __asan_report_load_n</div>
<div>00000560 T __asan_report_store1</div><div><div>00000620 T __asan_report_store16</div><div>00000590 T __asan_report_store2</div><div>000005c0 T __asan_report_store4</div><div>000005f0 T __asan_report_store8</div><div>
00000680 T __asan_report_store_n</div><div>00000720 T __asan_set_death_callback</div><div>000006b0 T __asan_set_error_exit_code</div><div>00000470 T __asan_get_current_allocated_bytes</div><div>00000580 T __asan_get_free_bytes</div>
<div>00000500 T __asan_get_heap_size</div><div>00000630 T __asan_get_unmapped_bytes</div><div>00000640 T __asan_print_accumulated_stats</div></div><div><br></div><div>I think we can generate and save this to lib/clang/3.3/lib/linux/libclang_rt.asan-x86_64.a.symbols (and distribute it together with .a file, gr-r-r).</div>
<div>Then, if driver can find the required file with symbols, it adds "--dynamic-list <...>.symbols" flag, or adds "--export-dynamic" otherwise.</div><div>Does this make sense?</div></div></div>
</div></div></blockquote><div><br></div><div>It turns out there's no need to generate the file during the build; the --dynamic-list file can contain patterns like "__asan_*". Done in r177783 and r177784, though we only generate the .syms file in the CMake build so far.</div>
</div>