This is the mail archive of the 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 Fri, Apr 19, 2013 at 7:59 AM, Christophe Lyon
<> wrote:
> On 18 April 2013 11:30, Christophe Lyon <> wrote:
>> On 4 April 2013 14:19, Christophe Lyon <> 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 <> 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
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.

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