On 6/17/20 9:00 AM, Shuai Wang wrote:
Dear Martin,

Thanks for the kind reply.

Hey.

You're welcome.

I don't have a strong preference between `asan0` vs. `sanopt`. But I note that 
I am primarily working on sanitizer enabled code, where I can only find some 
.ASAN_CHECK function calls in `asan0`, but those function calls seem have been 
inlined in `sanopt`.

Note that .ASAN_CHECK is not inlined but "instrumented". The function is about 
taking look in the shadow memory
and checking that a memory write is valid.

In other words, I can constantly find the following pattern:

*if (_44 != 0)*
     goto <bb 9>; [0.05%]
   else
     goto <bb 8>; [99.95%]

   <bb 9> :
   __builtin___asan_report_load4 (_34);

The marked if condition is where my analysis and instrumentation starts from. 
If I go with `asan0`, then I just cannot find it (it's somewhat wrapped within 
.ASAN_CHECK).

Can you please explain which ASAN_CHECKs are you trying to modify? We can 
probably find a proper
place where to implement your plugin-in functionality.

Martin


Best,
Shuai

On Wed, Jun 17, 2020 at 2:49 PM Martin Liška <mli...@suse.cz 
<mailto:mli...@suse.cz>> wrote:

    On 6/17/20 4:10 AM, Shuai Wang via Gcc wrote:
     > Hello,
     >
     > Suppose I have changed certain if condition in the GIMPLE code (generated
     > by the `sanopt` pass) into the following format:

    Hello.

    What kind of instrumentation are you doing? Can you make the instrumentation
    in a ASAN pass? Then you'll go through DCE.

    Martin

     >
     > if (0 == 1)
     > {
     >     xxxx
     > }
     >
     > Then, in order to completely remove this unnecessary if condition and the
     > guarded true branch, I want to leverage the dead code elimination
     > optimization of gcc. However, I just cannot figure out a way of doing 
so. I
     > use the following command to output the instrumented GIMPLE code:
     >
     > gcc -fdump-tree-all -fplugin=./instrumentor.so -g -fsanitize=address 
test.c
     >
     > And notice that the instrumented gimple code is right there in the
     > outputs: test.c.322t.instrumentor. Everything seems fine.
     >
     > Anyone could shed some light on how to re-optimize (e.g., with deadcode
     > elimination or just use -O3 if possible) the instrumented GIMPLE code?
     > Thank you very much.
     >
     > Shuai
     >


Reply via email to