On 6/17/20 9:10 AM, Shuai Wang wrote:
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).
That seems very close to what we do in maybe_optimize_asan_check_ifn
(sanopt.c). There we make a decision
if a ASAN_CHECK should be expanded or optimized out. You may implement your
functionality to the place.
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)...
I see.
Note that I'm not a plug-in guy, but more a GCC developer. That's why I prefer
direct modifications
to the compiler rather than offloading work to a plug-in ;)
Martin
Shuai
On Wed, Jun 17, 2020 at 3:05 PM Martin Liška <mli...@suse.cz
<mailto: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>
<mailto: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
> >
>
