[PATCH] D12763: [PATCH] [compiler-rt] [sanitizers] Add VMA size check at runtime

[Kristof Beyls via llvm-commits]

kristof.beyls added a comment.

In http://reviews.llvm.org/D12763#244134, @rengolin wrote:

> In http://reviews.llvm.org/D12763#244128, @kristof.beyls wrote:
>
> > I would have assumed it would be relatively straightforward to support multiple virtual-memory address space sizes in a single compiler-rt library, by adding name mangling to the public functions in the library that need to behave differently for different VMA sizes. E.g. couldn't a name mangling scheme adding "_vma39/_vma42/_vma48" be used to get all the functions depending on VMA size into a single compiler-rt library?
>
>
> Hi Kristof,
>
> The main issue here is run time impact of the decisions, and how it led the development of the sanitizers, and that's a topic not suitable to a small patch like this. :)
>
> It should be possible to come up with a clean design to make run time decisions cheaper and more elegant, and we're discussing this on IRC, mailing list and privately. There will be a session at Connect to discuss this with the ARM GCC team, and if you guys are interested, I'll send you the invite.
>
> But even so, none of that will give us any final direction, it'll be just an informal talk. The real discussion will happen in the list, hopefully also in the US LLVM meeting, so we can come up with a final design that doesn't regress performance and gets us our run time VMA choice.
>
> The sanitizers were developed with the mindset that there is only one memory map per architecture and that's hard-coded into the pre-processor macros. We'll need a bunch of small refactorings before we can start thinking about name mangling. For now, we need some mechanism that works.
>
> cheers,
> --renato


I don't see why name mangling would add run-time overhead - but it would avoid having to build different variants of compiler-rt for AArch64.
If name mangling does add run-time overhead, could you explain why?


http://reviews.llvm.org/D12763