On Fri, Apr 19, 2013 at 7:59 AM, Christophe Lyon <christophe.l...@linaro.org> wrote: > 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
For the issue with colors: Evgeniy, you probably want to implement something like ASAN_OPTIONS=color=0 to fight https://code.google.com/p/address-sanitizer/issues/detail?id=174 This will also help with quemu. > 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.
