| Message ID | 54639077.9090709@arm.com |
|---|---|
| State | New |
| Headers | show |
On 11/12/14 09:53, Ramana Radhakrishnan wrote: > Hi, > > One of the problems we appear to face with multilib testing > especially with conflicting ABIs in the ARM world is the occasional case > where a testglue file is built for one ABI but gets linked against a > multilib test invocation with another target. > > We've tried to ameliorate this in some of our builds with something > like this attached patch and we've been carrying this internally for > quite some time. In general this appears to help in quite a few cases > but there are still clashes that we get in our testing environment once > a while that we are unable to remove or get to the bottom of. (My > suspicion is around mov_if_change gcc-testglue{pid}.o gcc-tg.o but I'm > not yet a 100% sure.) > > This appears to reduce the number of clashes we have with such > conflicting ABIs and their testing thereof. I don't know if other folks > see such issues but it's worth checking if this is of use somewhere else. > > At the minute this is just an RFC to see what other folks think of this > and whether others face such an issue. > > Tested in the past for arm-none-eabi regularly built with > --with-multilib-list=aprofile with a set of conflicting multilib ABI tests. > > I'm happy to retest and resubmit if folks think this is a good idea. It's been a very long time since I had to deal with wrapping and multilib testing. *But* I can recall stumbling over this kind of problem in the past. Is it an issue with running the tests in parallel, or is it specific tests that are calling for non-default ABI and picking up a testglue built for the some other ABI? Jeff
On Nov 12, 2014, at 8:53 AM, Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> wrote:
> One of the problems we appear to face with multilib testing especially with conflicting ABIs in the ARM world is the occasional case where a testglue file is built for one ABI but gets linked against a multilib test invocation with another target.
Yeah, this is a natural consequence of doing more things in parallel. I’d let Jakub think about it for a minute and see if he sees a better (more invisible way) to fix this. If not, Ok (with what ever little clean-ups you might want to do).
diff --git a/gcc/testsuite/lib/g++.exp b/gcc/testsuite/lib/g++.exp index 751e27b..c23b409 100644 --- a/gcc/testsuite/lib/g++.exp +++ b/gcc/testsuite/lib/g++.exp @@ -233,7 +233,7 @@ proc g++_init { args } { unset gluefile } - g++_maybe_build_wrapper "${tmpdir}/g++-testglue.o" "-fexceptions" + g++_maybe_build_wrapper "[g++_wrap_filename ${tmpdir}]" "-fexceptions" if {![info exists CXXFLAGS]} { set CXXFLAGS "" diff --git a/gcc/testsuite/lib/gcc.exp b/gcc/testsuite/lib/gcc.exp index 49394b0..6b20e2b 100644 --- a/gcc/testsuite/lib/gcc.exp +++ b/gcc/testsuite/lib/gcc.exp @@ -113,7 +113,7 @@ proc gcc_init { args } { set gcc_warning_prefix "warning:" set gcc_error_prefix "error:" - gcc_maybe_build_wrapper "${tmpdir}/gcc-testglue.o" + gcc_maybe_build_wrapper "[gcc_wrap_filename ${tmpdir}]" } # diff --git a/gcc/testsuite/lib/gfortran.exp b/gcc/testsuite/lib/gfortran.exp index c9b5d64..936f787 100644 --- a/gcc/testsuite/lib/gfortran.exp +++ b/gcc/testsuite/lib/gfortran.exp @@ -190,7 +190,7 @@ proc gfortran_init { args } { unset gluefile } - gfortran_maybe_build_wrapper "${tmpdir}/gfortran-testglue.o" + gfortran_maybe_build_wrapper "[gfortran_wrap_filename ${tmpdir}]" set ALWAYS_GFORTRANFLAGS "" diff --git a/gcc/testsuite/lib/go.exp b/gcc/testsuite/lib/go.exp index d674f48..ce83132 100644 --- a/gcc/testsuite/lib/go.exp +++ b/gcc/testsuite/lib/go.exp @@ -172,7 +172,7 @@ proc go_init { args } { unset gluefile } - go_maybe_build_wrapper "${tmpdir}/go-testglue.o" + go_maybe_build_wrapper "${tmpdir}/go-testglue.o" "" set ALWAYS_GOCFLAGS "" diff --git a/gcc/testsuite/lib/wrapper.exp b/gcc/testsuite/lib/wrapper.exp index 1291c11..217d0eb 100644 --- a/gcc/testsuite/lib/wrapper.exp +++ b/gcc/testsuite/lib/wrapper.exp @@ -44,3 +44,13 @@ proc ${tool}_maybe_build_wrapper { filename args } { } } } + +proc ${tool}_wrap_filename { tmpdir } { + global tool + + set twrapper "${tmpdir}/${tool}-testglue" + append twrapper [getpid] + append twrapper ".o" + + return $twrapper +}
Hi, One of the problems we appear to face with multilib testing especially with conflicting ABIs in the ARM world is the occasional case where a testglue file is built for one ABI but gets linked against a multilib test invocation with another target. We've tried to ameliorate this in some of our builds with something like this attached patch and we've been carrying this internally for quite some time. In general this appears to help in quite a few cases but there are still clashes that we get in our testing environment once a while that we are unable to remove or get to the bottom of. (My suspicion is around mov_if_change gcc-testglue{pid}.o gcc-tg.o but I'm not yet a 100% sure.) This appears to reduce the number of clashes we have with such conflicting ABIs and their testing thereof. I don't know if other folks see such issues but it's worth checking if this is of use somewhere else. At the minute this is just an RFC to see what other folks think of this and whether others face such an issue. Tested in the past for arm-none-eabi regularly built with --with-multilib-list=aprofile with a set of conflicting multilib ABI tests. I'm happy to retest and resubmit if folks think this is a good idea. regards Ramana 2014-11-12 Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> * lib/wrapper.exp ${tool}_wrap_filename (): Define * lib/g++.exp (g++_init): Use appropriate filename for wrapper file. * lib/gcc.exp (gcc_init): Likewise. * lib/gfortran.exp (gfortran_init): Likewise. * lib/go.exp (go_init): Likewise.