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>
On 17 June 2011 08:55, Kostya Serebryany <kcc at google.com> wrote:> I am rather reluctant to add 'generic' code that handles unknown/untested > platforms because the memory mapping is very platform specific anyway.Indeed, but the point of that is more for helping writing platform-specific versions than actually using it as a general-purpose routine. Kinda documentation of your intentions on C, which is better than ASM. If you're lucky, it might even work... ;)> 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.I got a bit confused there, TBH. How do you guarantee that that part of memory will be allocated? If I'm not mistaken, the Native Client guys have done a memory place-holder, with enough space pre- and post-code, is it similar of what you're doing? Or are you using a big BSS region? Depending on how you did it, it might just work on other platforms... cheers, --renato
On Fri, Jun 17, 2011 at 12:04 PM, Renato Golin <rengolin at systemcall.org>wrote:> On 17 June 2011 08:55, Kostya Serebryany <kcc at google.com> wrote: > > I am rather reluctant to add 'generic' code that handles unknown/untested > > platforms because the memory mapping is very platform specific anyway. > > Indeed, but the point of that is more for helping writing > platform-specific versions than actually using it as a general-purpose > routine. Kinda documentation of your intentions on C, which is better > than ASM. > > If you're lucky, it might even work... ;) >Maybe the fallback code should just use a function call. Much simpler for documentation purposes.> > > > > 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. > > I got a bit confused there, TBH. How do you guarantee that that part > of memory will be allocated?On 32-bit, the shadow region is: [0x28000000, 0x3fffffff]HighShadow[0x24000000, 0x27ffffff]ShadowGap[0x20000000, 0x23ffffff]LowShadow This is 0.5G total. So, I mmap all these three shadow subregions and 'mprotect' the ShadowGap. This is done at startup. If the mmap fails, an assert will fire. On 64-bit, the shadow looks like this: [0x0000140000000000, 0x00001fffffffffff]HighShadow[0x0000120000000000, 0x000013ffffffffff]ShadowGap[0x0000100000000000, 0x000011ffffffffff] LowShadow This is quite a lot, I can not mmap/mprotect this thing. So, I basically *hope* that it won't be used by anyone but the ASAN run time (of course, there are asserts here and there to check it). When some part of the shadow region is being written to (when we poison memory), SEGV happens and the SEGV handler mmaps the required region.> If I'm not mistaken, the Native Client > guys have done a memory place-holder, with enough space pre- and > post-code, is it similar of what you're doing?Not very similar. 64-bit NaCl mmaps 88G of address space. On 64-bit ASAN I need 16384G of RAM, which is a bit too much to mmap.> Or are you using a big > BSS region? > > Depending on how you did it, it might just work on other platforms... > > cheers, > --renato >--kcc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110617/0eeb93c7/attachment.html>