libsanitizer merge from upstream r175042

Jakub Jelinek jakub@redhat.com
Wed Feb 13 13:07:00 GMT 2013


On Wed, Feb 13, 2013 at 04:57:30PM +0400, Konstantin Serebryany wrote:
> On Wed, Feb 13, 2013 at 4:48 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Wed, Feb 13, 2013 at 04:32:33PM +0400, Konstantin Serebryany wrote:
> >> > Unfortunately, it seems everything fails with that change :( on Linux.
> >> > The problem is that the default prelink library range for x86_64 is
> >> > 0x3000000000LL to 0x4000000000LL, and that unfortunately overlaps
> >>
> >> Forgive my ignorance, what is the  default prelink library range?
> >
> > Prelink is a program of mine (see e.g.
> > http://people.redhat.com/jakub/prelink.pdf
> > ) that speeds up dynamic linking of programs.
> > It is used by default on various Linux distributions.
> 
> Can it be disabled somehow (for asan)?

No.  You can disable it for the whole system (prelink -ua), but that is not
a sane requirement to running sanitized programs.  There is
also LD_USE_LOAD_BIAS=0 env variable, but 1) that has to be set before
running the program, setting it from within libasan ctor is too late, and
more importantly 2) it still doesn't affect the mapping of the dynamic
linker.  So, with LD_USE_LOAD_BIAS=0 cat /proc/self/maps the
dynamic linker will be still mapped somewhere in the 0x3000000000 to
0x4000000000 range, just other shared libraries mapped in by the dynamic
linker, rather than kernel directly, will be placed at the randomized (and
usually high) addresses, typically 0x7fXXXXXXXXXX.

> If we enabled flexible mapping in the gcc build (making it more
> similar to the llvm build)
> we will be able to use the old 2^44 offset w/o changing the asan-rt.

Sure, but it will be then slower, I thought you are looking for ASAN speed
improvements.

> That's yet another set of spaghetti ifdefs.
> I'd rather revert the whole thing back to 2^44 than do that.

Please revert the two hunks now.  I'll try to implement it eventually and
try to convince you ;)

	Jakub



More information about the Gcc-patches mailing list