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

[Alexey Samsonov]

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?

> >>
> >>
> >> What do you think? Is this patch OK as-is, or do you want the more
> complete solution?
> >>
> >> Thanks!
> >> Richard
> >
> >
> >
> >
> > --
> > Alexey Samsonov, MSK
>



-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130319/df7cc58b/attachment.html>