Hi all,
Kernel Asan patches are currently being discussed in LKML. One of the
points raised during review was that KAsan requires GCC 5.0 which is
presumably unstable (e.g. compilation of kernel modules has been broken
for two months due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848).
On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote:
> Kernel Asan patches are currently being discussed in LKML. One of the points
> raised during review was that KAsan requires GCC 5.0 which is presumably
> unstable (e.g. compilation of kernel modules has been broken for two months
> due
On 09/18/2014 01:57 PM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 01:46:21PM +0400, Yury Gribov wrote:
Kernel Asan patches are currently being discussed in LKML. One of the points
raised during review was that KAsan requires GCC 5.0 which is presumably
unstable (e.g. compilation of kernel mod
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
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
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 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/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 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/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 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/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 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
Hello.
I would to introduce a new test case for an issue (PR63270). I was looking for
*.exp files and I expected that another test located in:
./gcc/testsuite/g++.dg/lto/pr63166_0.ii can be executed with: make check -k
RUNTESTFLAGS="lto.exp=pr63166*"
But without succeed. Another interesting is
On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
> The reason I'm doing this is that I want to understand why the total
> size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in
> 4.9
>
> I can compile the first stage OK, and the binaries are quite modest:
>
> -rwxr-xr-x
On Thu, Sep 18, 2014 at 5:37 PM, Ian Grant wrote:
>
> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>>
>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>> > The reason I'm doing this is that I want to understand why the total
>> > size of the binaries grew from around 10MB (gc
Snapshot gcc-4.8-20140918 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140918/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>> I can compile the first stage OK, and the binaries are quite modest:
>>
>> -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
>> -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev
On 18 September 2014 23:46, Ian Grant wrote:
> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>>> I can compile the first stage OK, and the binaries are quite modest:
>>>
>>> -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
On Thu, Sep 18, 2014 at 6:54 PM, Jonathan Wakely wrote:
> On 18 September 2014 23:46, Ian Grant wrote:
>> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
I can compile the first stage OK, and the binaries are quite modest:
>
On Thu, Sep 18, 2014 at 6:54 PM, Jonathan Wakely wrote:
> On 18 September 2014 23:46, Ian Grant wrote:
>> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
> Have you compared the binaries using size(1) instead of ls(1)?
Actually, when I look at the output of size I realise I don't know
what
On 19 September 2014 00:07, Ian Grant wrote:
>
> Actually, when I look at the output of size I realise I don't know
> what it means:
>
> ian3@jaguar:~/usr/libexec/gcc$ size i686-pc-linux-gnu/4.9.0/{cc1,f951}
>text databssdechexfilename
> 14965183 23708
On Thu, Sep 18, 2014 at 8:32 PM, Jonathan Wakely wrote:
>> ian3@jaguar:~/usr/libexec/gcc$ size i686-pc-linux-gnu/4.9.0/{cc1,f951}
>>text databssdechexfilename
>> 14965183 23708 74494415733835 f0144b
>> i686-pc-linux-gnu/4.9.0/cc1
>> 15882830
In case it isn't obvious, what I am interested in is how easily we can
know the problem of infeasibly large binaries isn't an instance of
this one:
http://livelogic.blogspot.com/2014/08/beware-insiduous-penetrator-my-son.html
Ian
(delurking)
Ian Grant writes:
> In case it isn't obvious, what I am interested in is how easily we can know
> the problem of infeasibly large binaries isn't an instance of this one:
>
> http://livelogic.blogspot.com/2014/08/beware-insiduous-penetrator-my-son.html
Ah, this is commonly calle
On Thu, Sep 18, 2014 at 9:37 PM, Joe Buck wrote:
> (delurking)
> Ah, this is commonly called the Thompson hack, since Ken Thompson
> actually produced a successful demo:
How do you know Thompson's attempt was the first instance? The
document I refer to in the blog is the "Unknown Air Force Repor
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Ian Grant
>
> And can anyone tell me what are the 'non-vanilla' sources?
"Vanilla source" refers to unmodified source (as distributed on gcc.gnu.org for
the case of gcc). This is in contrast to modified source from distr
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
28 matches
Mail list logo
