On Fri, Oct 10, 2014 at 11:13:11AM +0400, Maxim Ostapenko wrote:
> Adding Jakub.
>
> -Maxim
> On 10/09/2014 04:34 PM, Maxim Ostapenko wrote:
> >Hi,
> >
> >After enabling ASan, TSan and UBSan testsuites for installed toolchain,
> >many tests started to fail. This is caused by wrong logic in {asan, ubsan,
> >tsan}_finish
> >functions. Here, restore_ld_library_path is called, that is wrong, because
> >it drops some env variables ( GCC_EXEC_PREFIX, LD_LIBRARY_PATH, etc) to
> >state that was before gcc-dg.exp initialized testing environment, so
> >installed GCC will be confused to find some needed stuff later.
> >
> >Removing restore_ld_library_path from {asan, ubsan, tsan}_finish seems to
> >fix the issue.
> >
> >Tested on x86_64-pc-linux-gnu, ok to commit?
> >
> >-Maxim
>
> gcc/testsuite/ChangeLog:
>
> 2014-10-09 Max Ostapenko <m.ostape...@partner.samsung.com>
>
> * lib/asan-dg.exp (asan_finish): Remove
> restore_ld_library_path_env_vars.
> * lib/tsan-dg.exp (tsan_finish): Likewise.
> * lib/ubsan-dg.exp (ubsan_finish): Likewise.
That looks wrong to me, we don't want to keep the libsanitizer paths in
LD_LIBRARY_PATH* after we leave asan.exp etc.
So, perhaps instead save ld_library_path into some global variable
(like {a,t,ub}san_saved_ld_library_path) during {a,t,ub}san_link_flags
before appending there anything, and replace
restore_ld_library_path_env_vars
with
set ld_library_path ${a,t,ub}san_saved_ld_library_path
set_ld_library_path_env_vars
?
Jakub
