Does it work without restore_ld_library_path in {asan, ubsan, tsan}_finish?
I see two opportunities to fix the issue:
1) Implement a stack of saved contexts.
2) Implement new functions, say {asan, ubsan,
tsan}_restore_ld_library_path, to be able {asan, ubsan, tsan}_finish
functions restore context correctly.
What solution is preferable?
-Maxim
On 10/08/2014 01:02 PM, Marcus Shawcroft wrote:
On 1 October 2014 08:09, Maxim Ostapenko
<m.ostape...@partner.samsung.com> wrote:
Hi,
some time ago, Andrew wrote a patch that fixes PR58867
(http://patchwork.ozlabs.org/patch/286866/), but for some reasons it
wasn't committed to trunk.
This is resurrected Andrew's patch, extended to support Tsan testsuite.
Tested on x86_64-pc-linux-gnu, ok to commit?
-Maxim
Hi,
This patch results in wide spread failures in our bare metal test
runs. I have not dug into the issue in detail but it appears that the
issue is related to the attempted use of set_ld_library_path_env_vars
and restore_ld_library_path_env_vars to save and restore nested
contexts.
Consider ubsan/ubsan.exp:
load_lib gcc-dg.exp
...
dg-init
ubsan_init
...
ubsan_finish
The gcc-dg.exp library load calls set_ld_library_path_env_vars the
first time an initializes GCC_EXEC_PREFIX.
The ubsan_init call makes a further call to
set_ld_library_path_env_vars which has no effect.
The ubsan_finish invokes restore_ld_library_path_env_vars, restoring
the environments as it was prior to the call to dg-init.
Any further test execution has now lost the original initialization of
GCC_EXEC_PREFIX by gcc-dg.exp
It seems to me that either this patch assumes that the
set/restore_ld_library_path_env foo is capable of maintaining a stack
of saved contexts... which it is not.
Prior to this patch ubsan_finish did not attempt to call
restore_ld_library_path_env_vars hence the gcc-dg.exp environment
remained in place for subsequent test executions.
Cheers
/Marcus
