This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][PR lto/79061] Fix LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco".
- From: Richard Biener <rguenther at suse dot de>
- To: Maxim Ostapenko <m dot ostapenko at samsung dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Wed, 18 Jan 2017 14:00:26 +0100 (CET)
- Subject: Re: [PATCH][PR lto/79061] Fix LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco".
- Authentication-results: sourceware.org; auth=none
- References: <CGME20170118075439eucas1p1f216c219e19fc0e5f19832a382b15af7@eucas1p1.samsung.com> <587F1F3A.6050208@samsung.com>
On Wed, 18 Jan 2017, Maxim Ostapenko wrote:
> Hi,
>
> as was figured out in PR LTO + ASan raises false initialization order fiasco
> alarm due to in LTO case main_input_filename doesn't match module name passed
> to __asan_before_dynamic_init.
> Following Jakub's suggestion I used TRANSLATION_UNIT_DECL for corresponding
> globals to overcome this issue (I needed to create a source location for each
> TRANSLATION_UNIT_DECL).
> However, when testing, I hit on a nasty issue: for some reason
> linemap_ordinary_map_lookup, called from lto_output_location for given
> TRANSLATION_UNIT_DECL, hit an assert:
>
> [...]
> linemap_assert (line >= MAP_START_LOCATION (result));
> return result;
> }
>
> due to line == 2.
>
> After some investigation I noticed that source locations are propagated
> through location cache that can be partially invalidated by
> lto_location_cache::revert_location_cache call. And that was my case: after
> adding source location for TRANSLATION_UNIT_DECL into location cache, it was
> reverted by calling lto_location_cache::revert_location_cache from unify_scc
> before it was accepted:
>
> static void
> lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
> vec<ld_plugin_symbol_resolution_t> resolutions)
> {
> [...]
> /* Try to unify the SCC with already existing ones. */
> if (!flag_ltrans
> && unify_scc (data_in, from,
> len, scc_entry_len, scc_hash))
> continue;
>
> For now I can overcome it by calling location_cache.accept_location_cache for
> TRANSLATION_UNIT_DECL, but I wonder if more reliable fix is possible.
>
> Attached patch fixes the issue mentioned in PR and passes regression testing
> and LTO bootstrap on x86_64-unknown-linux-gnu.
> Could you please take a look on it?
Looks good to me (aka, OK).
Thanks,
Richard.
> -Maxim
>
--
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)