[LLVMdev] LLVM-based address sanity checker

[Kostya Serebryany]

On Fri, Jun 17, 2011 at 11:48 AM, Renato Golin <rengolin at systemcall.org>wrote:

> On 16 June 2011 20:57, Kostya Serebryany <kcc at google.com> wrote:
> >> I see, maybe you could leave your C implementation as a fall back.
> >
> > Not easy, because it will require a fallback code in the run time
> library.
> > But yes, possible.
>
> I was thinking more of a build-time fall back, when you're choosing
> the platform...
>
> #ifdef __x86_arch
> ... specific
> #else
> C-generic
> #endif
>

Sure, this is possible. But we'll need  two such blocks: one in the LLVM
instrumentation and one (matching) in the run-time.
I am rather reluctant to add 'generic' code that handles unknown/untested
platforms because the memory mapping is very platform specific anyway.
For extreme performance ASAN uses the fixed memory-to-shadow mapping
(addr>>3)+offset. I guess there are plenty of platforms where this mapping
won't work or will require different offset.

--kcc


>
>
>
> > Agree. We've been adding APPLE code just recently. Time to split.
> > I afraid we'll have to keep a single .cc file and add .h files for
> os/arch
> > specific code to keep inlining under manual control (I don't want to
> reply
> > on the compiler doing cross-cc-file inlining for me).
>
> You might end up with a lot of redundancy.
>
> If inlining is not working as you'd expect, a compile-time static
> include (is ugly, but) would be better than to have the same code over
> and over.
>
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110617/16667818/attachment.html>