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
