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 <[email protected]>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
