On Thu, Aug 8, 2013 at 5:55 AM, Ramana Radhakrishnan <ramra...@arm.com> wrote:
> On 08/06/13 22:39, Benjamin De Kosnik wrote:
>>
>>
>>>> +# Filter out unsupported systems.
>>>> +case "${target}" in
>>>> + x86_64-*-linux* | i?86-*-linux*)
>>>> + VTV_SUPPORTED=yes
>>>> + ;;
>>>> + powerpc*-*-linux*)
>>>> + ;;
>>>> + sparc*-*-linux*)
>>>> + ;;
>>>> + arm*-*-linux*)
>>>> + ;;
>>>
>>>
>>> What about powerpc, sparc and arm? Why are they mentioned here if no
>>> actual decision is made about support?
>>
>>
>> This is more a practical consideration: it's the middle of summer
>> break. Let's error on the side of caution for the moment, and get
>> this in causing minimal disruption on a convenient platform that I can
>> verify myself easily.
>>
>> Once this is in trunk, let a million flowers bloom! There is no
>> reason specific platform/target maintainers can't enable it at their
>> leisure on a per-setup manner and when they can verify testresults
>> easily.
>
>
>
> arm*-*-linux* is broken currently for what looks like the same reasons as
> the powerpc port.
>
Have you tried Benjamin Kosnik's patch? Does it fix the problem?
> I spent some time this morning looking into what it would take to enable
> this for arm*-*-linux* today and the first thing that I noticed is that the
> testsuite is essentially driven by a shell script that caters to native
> testing on the only port that this was developed for. It also expects -m32
> and -m64 to be a standard option in all ports that want to turn this on.
> Also because the tests are not using dejagnu it's going to be a right pain
> to get this to work for cross-testing and unless that works reliably one
> isn't going to be able to get this feature working easily.
>
> Also whatever is target specific in the testsuite like environment-fail-32.s
> and environment-fail-64.s needs to live in it's own target folders.
> Basically this feature needs to follow conventions that exist already in
> other parts of the source base or atleast have plans to get there surely ?
>
> I haven't seen this in the reviews that I've seen so far, so apologies if
> this has already been raised.
>
I know that the testsuite, as committed, is not in DejaGnu format and
that it will need to be converted to DejaGnu format. I also know that
it is currently specific to the platform on which the feature was
developed. The plan has always been to fix this. There was some
private discussion about whether it would be better to commit the
testsuite in its current state or not to commit a testsuite at all
with the initial project commit. I was told that it would be better
to show that there is some way of testing this feature, even if the
testsuite is not in its final form, than to not show any way of
testing it at all.
I will work on getting the testsuite into a better form and also on
writing up some documentation on the platform-specific pieces of the
vtable verification feature (for those who wish to port it to other
platforms).
