On January 18, 2017 5:17:12 PM GMT+01:00, Maxim Ostapenko
<m.ostape...@samsung.com> 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?
Yes.
Richard.
>
>-Maxim
>
>>
>> Thanks,
>> Richard.
>>
>>> -Maxim
>>>
