On 18 April 2013 11:30, Christophe Lyon <christophe.l...@linaro.org> wrote:
> On 4 April 2013 14:19, Christophe Lyon <christophe.l...@linaro.org> wrote:
>> ~/src/qemu/qemu-git/arm-linux-user/qemu-arm -cpu cortex-a9 -R 0 -L
>> /home/lyon/src/GCC/builds/gcc-fsf-asan-arm-none-linux-gnueabihf/sysroot
>> ./heap-overflow-1.arm
>>
>> On 28 March 2013 15:33, Christophe Lyon <christophe.l...@linaro.org> wrote:
>>>>> - libsanitizer detects if its output is a tty, and when GCC testsuite
>>>>> is executed under qemu, libsanitizer concludes that it is actually
>>>>> running under a tty, and adds beautyfying characters which confuse
>>>>> dejanu.
>>>>
>>>> Is this again a quemu problem?
>>> I still don't know. I tried to investigate some time ago; I thought it
>>> could be a problem when qemu interprets a ~isatty syscall, but IIRC
>>> this syscall isn't used. So I don't know who finally asnwers to the
>>> isatty() query.
>>>
>>
>> After a bit more debugging, the libsanitizer query isatty(2) is
>> handled by glibc as a call to __tcgetattr(2,...), which is turned into
>> ioctl(2, TCGETS,...).
>>
>> Qemu issues the same query to the host, and I have observed that when
>> called by expect, qemu's fd 2 points to /dev/pts/XXX which explains
>> why it thinks it is a tty.
>>
>> So far I have haven't look at what actually happens when executed on a
>> board, but why would expect behave differently?
>>
>
> After debugging on ARM hardware, I noticed that in this latter case,
> runtest uses "unix" as target, and uses pipes to communicate with the
> test program, while it creates ptys when using a simulator.
> By adding the "readonly" flag in sim_spawn
> (/usr/share/dejagnu/config/sim.exp) I managed to have these tests pass
> under qemu, but I don't know if this is safe or if there is a better
> way of achieving the same effect.
>
> However, doing this makes other tests fail "harder": the tests
> involving clone() fail when run under qemu, but when the "readonly"
> flag is set, qemu sometimes fail in timeout rather than exiting with
> an error code. Threads in general are not well supported by qemu
> (there are other random failures in GCC testsuite related to this).
>
> So.... maybe it would be better to skip asan tests when running under
> qemu: is the GCC testsuite aware of being run under qemu?
>
> Thanks for any suggestion.
>
Replying to myself:
I have added a new check_effective_target_hw function in the
testsuite, to enable to skip tests when running under a simulator.
My concern is that in this particular case, it's a problem with a
particular simulator (qemu-user), not simulators in general (ie it's
not a speed problem).
So, should/could I add another variable that people would set when using qemu?
For the record, we have to skip clone-test-1.c and
rlimit-mmap-test-1.c because qemu isn't currently able to run them
(whatever the target).
Regarding the isatty(2) problem discussed earlier, I can workaround it
by modifying the regexps in dg-output clauses such as:
-/* { dg-output "AddressSanitizer can not provide additional
info.*(\n|\r\n|\r)" } */
+/* { dg-output ".*AddressSanitizer can not provide additional
info.*(\n|\r\n|\r)" } */
What do people think about this proposal?
Christophe.
