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: [google] AddressSanitizer for gcc, first attempt. (issue 5272048)


There must be a style lint for gcc -- but I have not used it ..


http://codereview.appspot.com/5272048/diff/2001/tree-asan.c File tree-asan.c (right):

http://codereview.appspot.com/5272048/diff/2001/tree-asan.c#newcode79
tree-asan.c:79: (All I need is to traverse *all* memory accesses and
instrument them).
For refs such as component ref  'ap->b[i].c',  you need to create the
access address expression out of it -- you may want to try to use
build_addr interface.  There is another interface
get_ref_base_and_extent which can return the access base + offset, but
it does not work for asan when there is array ref with runtime index --
this is mainly for alias analysis.


On 2011/10/17 23:04:50, kcc wrote:
On 2011/10/17 22:33:17, davidxl wrote:
> Discard 2) -- it is not correct.  What Asan needs is slightly
different.

Yea.
I actually have a test where this instrumentation does something bad.


http://codereview.appspot.com/5272048/diff/2001/tree-asan.c#newcode128
tree-asan.c:128: /* perform the instrumentation */
On 2011/10/17 23:04:50, kcc wrote:
On 2011/10/17 22:26:55, davidxl wrote:
> Parameter documentation. s/perform/Perform/
Done, although I am not sure what location is...

location is the source location.


http://codereview.appspot.com/5272048/diff/2001/tree-asan.c#newcode286
tree-asan.c:286: transform_derefs (gimple_stmt_iterator *iter, tree *tp,
Look at interface build_addr in tree-nested.c, it may be what you need.

On 2011/10/17 23:04:50, kcc wrote:
On 2011/10/17 22:26:55, davidxl wrote:
> You can use get_base_address utility function defined in gimple.c

So, do I ignore this for now?

http://codereview.appspot.com/5272048/diff/2001/tree-asan.c#newcode414 tree-asan.c:414: do Ok, in that case, may be you should use the aux field of BB to mark those new BBs and skip them?

On 2011/10/17 23:04:50, kcc wrote:
On 2011/10/17 22:26:55, davidxl wrote:
> Can you use FOR_EACH_BB macro?

I don't know. Can I? The instrumentation code creates new BB while it
runs and
those should not be instrumented.

http://codereview.appspot.com/5272048/



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