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?