On Thu, Sep 18, 2014 at 10:42 PM, Yury Gribov wrote:
> On 09/18/2014 09:33 PM, Dmitry Vyukov wrote:
>>
>> What is the number of cases it will fix for kasan?
>
>
> Re-added kernel people again.
>
> AFAIR silly instrumentation that assumed all memory accesses in inline asm
> are must-accesses (inste
On 09/18/2014 09:33 PM, Dmitry Vyukov wrote:
What is the number of cases it will fix for kasan?
Re-added kernel people again.
AFAIR silly instrumentation that assumed all memory accesses in inline
asm are must-accesses (instead of may-accesses) resulted in only one
false positive. We haven't
On 09/18/14 08:32, Richard Biener wrote:
On September 18, 2014 3:36:24 PM CEST, Jeff Law
wrote:
On 09/18/14 05:19, Yury Gribov wrote:
Would that modifier mean that the inline asm is
unconditionally
reading
resp. writing that memory? "m"/"=m" right now is always about
might read or might wri
On 09/18/14 08:38, Yury Gribov wrote:
On 09/18/2014 05:36 PM, Jeff Law wrote:
On 09/18/14 05:19, Yury Gribov wrote:
Would that modifier mean that the inline asm is unconditionally reading
resp. writing that memory? "m"/"=m" right now is always about might
read or might write, not must.
Yes,
On Thu, Sep 18, 2014 at 4:09 AM, Yury Gribov wrote:
> Hi all,
>
> Current semantics of memory constraints in GCC inline asm (i.e. "m", "v",
> etc.) is somewhat loosy in that it tells GCC that asm code _may_ access
> given amount of bytes but is not guaranteed to do so. This is (ab)used by
> e.g. g
On 09/18/2014 05:36 PM, Jeff Law wrote:
On 09/18/14 05:19, Yury Gribov wrote:
Would that modifier mean that the inline asm is unconditionally reading
resp. writing that memory? "m"/"=m" right now is always about might
read or might write, not must.
Yes, that's what I had in mind. Many inline
On September 18, 2014 3:36:24 PM CEST, Jeff Law wrote:
>On 09/18/14 05:19, Yury Gribov wrote:
>>>
>>> Would that modifier mean that the inline asm is unconditionally
>reading
>>> resp. writing that memory? "m"/"=m" right now is always about might
>>> read or might write, not must.
>>
>> Yes, that'
On 09/18/14 05:19, Yury Gribov wrote:
Would that modifier mean that the inline asm is unconditionally reading
resp. writing that memory? "m"/"=m" right now is always about might
read or might write, not must.
Yes, that's what I had in mind. Many inline asms (at least in kernel) do
read memory
On 09/18/2014 03:16 PM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 03:09:34PM +0400, Yury Gribov wrote:
Current semantics of memory constraints in GCC inline asm (i.e. "m", "v",
etc.) is somewhat loosy in that it tells GCC that asm code _may_ access
given amount of bytes but is not guaranteed
On 09/18/2014 03:09 PM, Yury Gribov wrote:
Hi all,
Current semantics of memory constraints in GCC inline asm (i.e. "m",
"v", etc.) is somewhat loosy in that it tells GCC that asm code _may_
access given amount of bytes but is not guaranteed to do so. This is
(ab)used by e.g. glibc (and also some
On Thu, Sep 18, 2014 at 03:09:34PM +0400, Yury Gribov wrote:
> Current semantics of memory constraints in GCC inline asm (i.e. "m", "v",
> etc.) is somewhat loosy in that it tells GCC that asm code _may_ access
> given amount of bytes but is not guaranteed to do so. This is (ab)used by
> e.g. glibc
Hi all,
Current semantics of memory constraints in GCC inline asm (i.e. "m",
"v", etc.) is somewhat loosy in that it tells GCC that asm code _may_
access given amount of bytes but is not guaranteed to do so. This is
(ab)used by e.g. glibc (and also some pieces of kernel):
__STRING_INLINE void
12 matches
Mail list logo
