[PATCH][PR lto/79061] Fix LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco".

[Richard Biener]

On Wed, 18 Jan 2017, Maxim Ostapenko wrote:

> 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?

So this regresses compile-time by 100% on some fortran cases.  Doing the
linemap operation in build_translation_unit_decl confuses the linemap
code too much it seems.

Please revert this (and not backport it) for now.

A better place to store the filename would be eventually the DECL_NAME
of it or a new field alongside TRANSLATION_UNIT_DECL_LANGUAGE.

Thanks,
Richard.

> -Maxim
> 
> > 
> > Thanks,
> > Richard.
> > 
> > > -Maxim
> > > 
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)