[PATCH] Remove -export-dynamic from sanitizer link lines

[Richard Smith]

On Tue, Mar 19, 2013 at 4:06 AM, Alexey Samsonov <samsonov at google.com>wrote:

> On Mon, Mar 18, 2013 at 9:40 AM, Richard Smith <richard at metafoo.co.uk>wrote:
>
>> On 17 Mar 2013 22:32, "Alexey Samsonov" <samsonov at google.com> wrote:
>> >
>> > +glider
>> >
>> > 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?
>> > If the workaround for users will be to manually add --export-dynamic to
>> the link command, we should mention it somewhere in the manual.
>> >
>> > On Sat, Mar 16, 2013 at 5:35 AM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> 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.
>> >>
>> >> 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.
>> >
>> >
>> > Do you plan to generate this list when building compiler-rt and store
>> it next to the runtime in the resource directory?
>>
>> I was intending to have a manually maintained list, but generating it
>> would be better.
>>
>  $ ./bin/llvm-nm lib/clang/3.3/lib/linux/libclang_rt.asan-x86_64.a | grep
> "T __asan"
> 000017b0 T __asan_get_allocated_size
> 00001760 T __asan_get_estimated_allocated_size
> 00001770 T __asan_get_ownership
> 000009e0 T __asan_stack_free
> 00000990 T __asan_stack_malloc
> 00000780 T __asan_after_dynamic_init
> 00000530 T __asan_before_dynamic_init
> 00000150 T __asan_register_globals
> 00000380 T __asan_unregister_globals
> 000006e0 T __asan_address_is_poisoned
> 000002e0 T __asan_poison_memory_region
> 000009e0 T __asan_poison_stack_memory
> 00000720 T __asan_region_is_poisoned
> 000004f0 T __asan_unpoison_memory_region
> 00000b30 T __asan_unpoison_stack_memory
> 000024f0 T __asan_describe_address
> 00001770 T __asan_report_error
> 000024b0 T __asan_set_error_report_callback
> 000006c0 T __asan_handle_no_return
> 00000730 T __asan_init_v2
> 00000470 T __asan_report_load1
> 00000530 T __asan_report_load16
> 000004a0 T __asan_report_load2
> 000004d0 T __asan_report_load4
> 00000500 T __asan_report_load8
> 00000650 T __asan_report_load_n
> 00000560 T __asan_report_store1
> 00000620 T __asan_report_store16
> 00000590 T __asan_report_store2
> 000005c0 T __asan_report_store4
> 000005f0 T __asan_report_store8
> 00000680 T __asan_report_store_n
> 00000720 T __asan_set_death_callback
> 000006b0 T __asan_set_error_exit_code
> 00000470 T __asan_get_current_allocated_bytes
> 00000580 T __asan_get_free_bytes
> 00000500 T __asan_get_heap_size
> 00000630 T __asan_get_unmapped_bytes
> 00000640 T __asan_print_accumulated_stats
>
> 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).
> Then, if driver can find the required file with symbols, it adds
> "--dynamic-list <...>.symbols" flag, or adds "--export-dynamic" otherwise.
> Does this make sense?
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130322/d063c6f5/attachment.html>