[llvm-commits] AddressSanitizer: start factoring out interception machinery (issue 5642046)

[samsonov at google.com]

http://codereview.appspot.com/5642046/diff/1/interception/interception.h
File interception/interception.h (right):

http://codereview.appspot.com/5642046/diff/1/interception/interception.h#newcode100
interception/interception.h:100: bool OverrideFunction(void *old_func,
void *new_func, void **orig_old_func);
On 2012/02/07 16:42:36, glider wrote:
> #define INTERCEPT_FUNCTION(func)
> #ifdef __linux__
> INTERCEPT_FUNCTION_LINUX(func)
> #elif __APPLE__
> ...

> WDYT?

> This won't dictate unnecessary interfaces to the systems that don't
need them
> and will hide this stuff from the user.

Where will you define INTERCEPT_FUNCTION_LINUX()? Anyway, the functions
that are called INTERCEPT_FUNCTION_LINUX will be inserted into user's
code, and thus user should have access to their definition. We can
discourage to use these functions themselves, though.

http://codereview.appspot.com/5642046/diff/1/interception/interception_mac.cc
File interception/interception_mac.cc (right):

http://codereview.appspot.com/5642046/diff/1/interception/interception_mac.cc#newcode71
interception/interception_mac.cc:71: orig_old_func,
On 2012/02/07 16:42:36, glider wrote:
> On 2012/02/07 14:31:32, samsonov wrote:
> > On 2012/02/07 13:14:29, glider wrote:
> > > mach_override_ptr_custom should have a custom prefix, too.
> >
> > So, you'd need different mach_override_ptr for each tool?
(disregarding custom
> > allocate/deallocate island)

> We'll need an option to prepend a custom prefix to it.
> I'll do that later in mach_override (I had asked Jonathan about that,
but he
> hasn't responded yet)

OK, I guess we can deal with it a bit later.

http://codereview.appspot.com/5642046/