On Mon, Mar 18, 2013 at 9:40 AM, Richard Smith <[email protected]>wrote:
> On 17 Mar 2013 22:32, "Alexey Samsonov" <[email protected]> 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 <[email protected]> > 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
