On 18/01/17 16:00, Richard Biener wrote:
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, applied as r244581. Is it OK to commit the patch on branches if
no new errors pop up in the next few days?
-Maxim
Thanks,
Richard.
-Maxim
