On Tue, Mar 19, 2013 at 4:06 AM, Alexey Samsonov <[email protected]>wrote:
> 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? > 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
