> Eric, Rainer, what do you think of the other two options I outlined in
> my earlier message?
>
> 1- Copy the upstream testsuite into gcc/testsuite/asan. This gives us
> the flexibility of adding new tests as the GCC implementation matures.
>
> 2- Deal with libasan as we deal with zlib/boehm-gc
On 2012-10-16 18:50 , Ian Lance Taylor wrote:
That is fine with me as long as we acknowledge that the upstream
sources don't care about GCC and will think it is absurd that they
should modify their code to carry untested and unmaintained
GCC-specific annotations. It would be one thing if the GC
On Tue, Oct 16, 2012 at 2:33 PM, Eric Botcazou wrote:
>> Yes, that is true. But when you say "if this trend continues" you are
>> making a slippery slope argument that I don't think applies. To date,
>> the trend consists of a single example. We are discussing adding a
>> second example, and we
> Yes, that is true. But when you say "if this trend continues" you are
> making a slippery slope argument that I don't think applies. To date,
> the trend consists of a single example. We are discussing adding a
> second example, and we may decide against it. There are no current
> prospects o
On Tue, Oct 16, 2012 at 10:40 AM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 09:48:28AM -0700, Xinliang David Li wrote:
>> The way to do this is not to use the shadow memory, but to clobber
>> directly the variable itself with specified byte pattern -- though
>> error diagnostics won't be as n
On Tue, Oct 16, 2012 at 09:48:28AM -0700, Xinliang David Li wrote:
> The way to do this is not to use the shadow memory, but to clobber
> directly the variable itself with specified byte pattern -- though
> error diagnostics won't be as nice.
Clobbering the memory directly is definitely easy, but
The way to do this is not to use the shadow memory, but to clobber
directly the variable itself with specified byte pattern -- though
error diagnostics won't be as nice.
To use shadow memory, the scope start marker is also needed.
David
On Tue, Oct 16, 2012 at 9:12 AM, Jakub Jelinek wrote:
> On
On Tue, Oct 16, 2012 at 09:06:22AM -0700, Xinliang David Li wrote:
> I don't get it. Clobber marks the end of lifetime of a variable so it
> is safe to emit code to really clobber its value -- otherwise how
> would clobber based slot sharing work?
If you at CLOBBER protect the var in the shadow m
On Mon, Oct 15, 2012 at 11:12 PM, Jakub Jelinek wrote:
> On Mon, Oct 15, 2012 at 10:48:13PM -0700, Xinliang David Li wrote:
>> Another error checking feature is to poison stack vars on entry and
>> exit of the lexical scope to catch uninit variable reference and out
>> of scope references:
>>
>> S
On Mon, Oct 15, 2012 at 10:48:13PM -0700, Xinliang David Li wrote:
> Another error checking feature is to poison stack vars on entry and
> exit of the lexical scope to catch uninit variable reference and out
> of scope references:
>
> S* sp;
> {
> S s;
> sp = &s;
> }
> .. *sp ...
>
On Tue, Oct 16, 2012 at 4:05 AM, Rainer Orth
wrote:
>
> But importing different upstream testsuites with different annotation
> systems allows them to make GCC maintainer's lives miserable? If this
> trend continues, maintainers need to cope with several different
> annoation systems with differe
On 2012-10-16 07:05 , Rainer Orth wrote:
Diego Novillo writes:
On Mon, Oct 15, 2012 at 11:55 AM, Ian Lance Taylor wrote:
In my opinion, supporting the full range of GCC testsuite annotations
means imposing a lot of mechanism that the Go testsuite does not
require. It would complicate the G
Diego Novillo writes:
> On Mon, Oct 15, 2012 at 11:55 AM, Ian Lance Taylor wrote:
>
>> In my opinion, supporting the full range of GCC testsuite annotations
>> means imposing a lot of mechanism that the Go testsuite does not
>> require. It would complicate the Go testsuite for no benefit.
>> An
Another error checking feature is to poison stack vars on entry and
exit of the lexical scope to catch uninit variable reference and out
of scope references:
S* sp;
{
S s;
sp = &s;
}
.. *sp ...
This is relatively easy to do in gcc thanks to the clobber statement.
In Clang/LLVM, it i
On Mon, Oct 15, 2012 at 11:55 AM, Ian Lance Taylor wrote:
> In my opinion, supporting the full range of GCC testsuite annotations
> means imposing a lot of mechanism that the Go testsuite does not
> require. It would complicate the Go testsuite for no benefit.
> Anybody who can understand the GC
On Mon, Oct 15, 2012 at 7:31 AM, Rainer Orth
wrote:
> Ian Lance Taylor writes:
>
>> On Fri, Oct 12, 2012 at 9:40 AM, Jakub Jelinek wrote:
>>>
>>> I don't see how can their testcase be used if not converted to Dejagnu
>>> though, most of their testcases are full of LLVM testcase markup
>>> (// RU
Ian Lance Taylor writes:
> On Fri, Oct 12, 2012 at 9:40 AM, Jakub Jelinek wrote:
>>
>> I don't see how can their testcase be used if not converted to Dejagnu
>> though, most of their testcases are full of LLVM testcase markup
>> (// RUN, // CHECK*, etc.). So, if we import the library unmodified
On Fri, Oct 12, 2012 at 9:40 AM, Jakub Jelinek wrote:
>
> I don't see how can their testcase be used if not converted to Dejagnu
> though, most of their testcases are full of LLVM testcase markup
> (// RUN, // CHECK*, etc.). So, if we import the library unmodified,
> we'll need to setup some dire
On 2012-10-12 12:40 , Jakub Jelinek wrote:
On Fri, Oct 12, 2012 at 11:51:22AM -0400, Diego Novillo wrote:
On 2012-10-12 11:01 , Rainer Orth wrote:
Diego Novillo writes:
3- To run ASAN's testsuite, I propose a simple wrapper script that executes
it using the just-built gcc. I don't think it'
On Fri, Oct 12, 2012 at 11:51:22AM -0400, Diego Novillo wrote:
> On 2012-10-12 11:01 , Rainer Orth wrote:
> >Diego Novillo writes:
> >
> >>3- To run ASAN's testsuite, I propose a simple wrapper script that executes
> >>it using the just-built gcc. I don't think it's worth the pain to convert
> >>
On Fri, Oct 12, 2012 at 12:26 AM, Jakub Jelinek wrote:
> On Thu, Oct 11, 2012 at 10:05:54PM -0700, Xinliang David Li wrote:
>> Was:
>> Type global;
>> Now:
>> struct { // at least 32-byte aligned
>>Type orig;
>>char redzone[32 + required_for_alignment];
>> } global;
>>
On Fri, Oct 12, 2012 at 9:32 AM, Jakub Jelinek wrote:
> On Fri, Oct 12, 2012 at 09:30:33AM -0700, Xinliang David Li wrote:
>> > Yeah, I think the stack check shouldn't be that hard and can hack it up,
>> > I'll perhaps leave the global vars stuff to Dodji or others if he has time.
>>
>> Since the
On Fri, Oct 12, 2012 at 09:30:33AM -0700, Xinliang David Li wrote:
> > Yeah, I think the stack check shouldn't be that hard and can hack it up,
> > I'll perhaps leave the global vars stuff to Dodji or others if he has time.
>
> Since the stack part is relative self contained, might it be better
>
On Fri, Oct 12, 2012 at 12:15 AM, Jakub Jelinek wrote:
> On Thu, Oct 11, 2012 at 04:19:18PM -0700, Wei Mi wrote:
>> Here is the initial test results of gcc asan patch, and it shows us
>> some missing features in gcc but existing in llvm.
>> [1]. gcc regression test for gcc-asan passes.
>> [2]. llv
On 2012-10-12 11:01 , Rainer Orth wrote:
Diego Novillo writes:
3- To run ASAN's testsuite, I propose a simple wrapper script that executes
it using the just-built gcc. I don't think it's worth the pain to convert
the testsuite into DejaGNU.
If the testsuite is not converted (which can be ug
Diego Novillo writes:
> 3- To run ASAN's testsuite, I propose a simple wrapper script that executes
> it using the just-built gcc. I don't think it's worth the pain to convert
> the testsuite into DejaGNU.
If the testsuite is not converted (which can be ugly for maintainers
since it needs separ
On 2012-10-11 19:19 , Wei Mi wrote:> Hi,
>
> Here is the initial test results of gcc asan patch, and it shows us
> some missing features in gcc but existing in llvm.
> [1]. gcc regression test for gcc-asan passes.
> [2]. llvm regression tests for gcc-asan: 18 failures in 123 for tests
> written in
On Thu, Oct 11, 2012 at 7:31 PM, Jakub Jelinek wrote:
> On Thu, Oct 11, 2012 at 01:14:31PM -0400, Diego Novillo wrote:
>> On 2012-10-11 12:38 , Jakub Jelinek wrote:
>>
>> >- gimple_seq seq, stmts;
>> >- tree shadow_type = size_in_bytes == 16 ?
>> >- short_integer_type_node : char_type_node;
On Thu, Oct 11, 2012 at 04:19:18PM -0700, Wei Mi wrote:
> Here is the initial test results of gcc asan patch, and it shows us
> some missing features in gcc but existing in llvm.
> [1]. gcc regression test for gcc-asan passes.
> [2]. llvm regression tests for gcc-asan: 18 failures in 123 for tests
Hi,
Here is the initial test results of gcc asan patch, and it shows us
some missing features in gcc but existing in llvm.
[1]. gcc regression test for gcc-asan passes.
[2]. llvm regression tests for gcc-asan: 18 failures in 123 for tests
written in google test and 24 failures in 28 for tests writ
On Thu, Oct 11, 2012 at 11:12 AM, Jakub Jelinek wrote:
> On Thu, Oct 11, 2012 at 10:31:58AM -0700, Xinliang David Li wrote:
>> > +#define PROB_VERY_UNLIKELY (REG_BR_PROB_BASE / 2000 - 1)
>> > +#define PROB_ALWAYS(REG_BR_PROB_BASE)
>> > +
>>
>>
>> Does it belong here ? -- looks like
On Thu, Oct 11, 2012 at 10:31:58AM -0700, Xinliang David Li wrote:
> > +#define PROB_VERY_UNLIKELY (REG_BR_PROB_BASE / 2000 - 1)
> > +#define PROB_ALWAYS(REG_BR_PROB_BASE)
> > +
>
>
> Does it belong here ? -- looks like they can be generally useful for others.
Perhaps, but then i
Hi Diego,
>> /* Build
>> - (base_addr >> ASAN_SHADOW_SHIFT) | targetm.asan_shadow_offset ().
>> */
>> + (base_addr >> ASAN_SHADOW_SHIFT) + targetm.asan_shadow_offset ().
>> */
>
>
> Hm, I wonder if this is a documentation problem or we're generating bad
> runtime code. Wei, you tested
On Thu, Oct 11, 2012 at 9:38 AM, Jakub Jelinek wrote:
> Hi!
>
> Building trees, then gimplifying it, is unnecessarily expensive.
> This patch changes build_check_stmt to emit GIMPLE directly, and
> a couple of small cleanups here and there. Also, I'm using a different
> alias set for the shadow m
On Thu, Oct 11, 2012 at 01:14:31PM -0400, Diego Novillo wrote:
> On 2012-10-11 12:38 , Jakub Jelinek wrote:
>
> >- gimple_seq seq, stmts;
> >- tree shadow_type = size_in_bytes == 16 ?
> >- short_integer_type_node : char_type_node;
> >- tree shadow_ptr_type = build_pointer_type (shadow_type
On 2012-10-11 12:38 , Jakub Jelinek wrote:
- gimple_seq seq, stmts;
- tree shadow_type = size_in_bytes == 16 ?
- short_integer_type_node : char_type_node;
- tree shadow_ptr_type = build_pointer_type (shadow_type);
- tree uintptr_type = lang_hooks.types.type_for_mode (ptr_mode,
-
Hi!
Building trees, then gimplifying it, is unnecessarily expensive.
This patch changes build_check_stmt to emit GIMPLE directly, and
a couple of small cleanups here and there. Also, I'm using a different
alias set for the shadow memory accesses, those obviously can't alias any
other accesses.
O
37 matches
Mail list logo
