This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, ARM] Enable libsanitizer
- From: Christophe Lyon <christophe dot lyon at linaro dot org>
- To: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- Cc: Evgeniy Stepanov <eugenis at google dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Patch Tracking <patches at linaro dot org>
- Date: Thu, 18 Apr 2013 11:30:28 +0200
- Subject: Re: [Patch, ARM] Enable libsanitizer
- References: <CAKdteObkDtD99dihWAwZiAszRW2Qxpr=mA+bkc79Wp8V2Kmgyg at mail dot gmail dot com> <CAGQ9bdzS796KHnxDhpnA2YDuwUBD8hpf9oOC+cHKqkFKEk0N_Q at mail dot gmail dot com> <CAKdteOYuX-48zajPrzxtm-oA86ugTvGku4UXT5hndU2YKWVapw at mail dot gmail dot com> <CAKdteOa_L=otyJgSrSE2G6B+tSQf2TgibOOMRXp2y9FFttzVsA at mail dot gmail dot com>
On 4 April 2013 14:19, Christophe Lyon <firstname.lastname@example.org> wrote:
> ~/src/qemu/qemu-git/arm-linux-user/qemu-arm -cpu cortex-a9 -R 0 -L
> On 28 March 2013 15:33, Christophe Lyon <email@example.com> 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
>>> 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.