This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, ARM] Enable libsanitizer


On 4 April 2013 14:19, Christophe Lyon <christophe.lyon@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.lyon@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.

Christophe.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]