Dear Martin,
Thanks for the information. I am tentatively experimenting some random
gadgets; given the critical if condition belonging to each sanitizer check,
i will do some data flow analysis and then decide whether to remove that
check or not (done). If so, I will rewrite that if condition into always
false (done), and hope I can re-launch the dead code elimination pass of
GCC to automatically remove that particular sanitizer check (and the if
condition).
This is just some random hacks, so probably far from the adoption stage...
If it does, then i will be glad to reach out and discuss more on the
details (although i am not sure how it goes)...
Shuai
On Wed, Jun 17, 2020 at 3:05 PM Martin Liška <mli...@suse.cz> wrote:
> 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
> > >
> >
>
>
