Re: libsanitizer merge from upstream r175042

[Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>]

On Fri, Feb 22, 2013 at 8:32 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Feb 15, 2013 at 12:47:30PM +0400, Konstantin Serebryany wrote:
>> Sure. ASAN_FIXED_MAPPING should be used for performance measurements
>> only -- this is not a release option.
>> (Added a more precise comment).
>
> BTW, today I think I've discovered what looks like a prelink bug,
> but perhaps we need to bump kMidMemEnd a little bit.
> With prelink -R, the libraries are randomized in the selected range of addresses,
> by picking a random number in between the boundaries of the address range and first
> assigning addresses to libraries above that random offset and when there is no longer any room
> above it, starting from the beginning of the range.  Unfortunately the code seems to have
> some issues if the random address is chosen close to the end of the range, then in some
> cases some libraries could start before the range, but end after the range.
>
> On one of my boxes there is (only 4 libraries out of 822 have this problem,
> only discovered it because gdb is linked against one of them and I've tried to
> LD_PRELOAD=libasan.so.0 to gdb so that the debugged program would inherit that):
>
> prelink -pv 2>&1 | grep 0x0000003.*-.*0x0000004
> /usr/lib64/libgmlib.so.1.0.7 [0x1ea5b3cf] 0x0000003fffe00000-0x0000004000008460:
> /usr/lib64/libiec61883.so.0.1.1 [0x56363ffc] 0x0000003fffe00000-0x000000400000c3e0:
> /usr/lib64/libncurses.so.5.9 [0x120e1b8a] 0x0000003fffe00000-0x0000004000023860:
> /usr/lib64/libsoup-2.4.so.1.5.0 [0x99ff4d51] 0x0000003fffe00000-0x000000400006a258:
>
> while on others none.
>
> So, can kMidMemEnd be slightly incremented above this?  Either 0x4fffffffffULL,
> or 0x40ffffffffULL (or replace that 0f with 1f, 2f, etc.).
> Small model shared libraries can be only up to 2GB in size, so even
> 0x40ffffffffULL should be big enough for most cases, but 0x4fffffffffULL
> could be even safer.  I've justed tested and 0x4fffffffffULL results in
> || `[0x10007fff8000, 0x7fffffffffff]` || HighMem    ||
> || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow ||
> || `[0x005000000000, 0x02008fff6fff]` || ShadowGap3 ||
> || `[0x003000000000, 0x004fffffffff]` || MidMem     ||
> || `[0x000a7fff8000, 0x002fffffffff]` || ShadowGap2 ||
> || `[0x00067fff8000, 0x000a7fff7fff]` || MidShadow  ||
> || `[0x00008fff7000, 0x00067fff7fff]` || ShadowGap  ||
> || `[0x00007fff8000, 0x00008fff6fff]` || LowShadow  ||
> || `[0x000000000000, 0x00007fff7fff]` || LowMem     ||
> MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff 0x00014fff7000 0x0001cfff6fff
> and seems to work just fine.

I am sorry, I missed this message.
Indeed, the change looks safe,
http://llvm.org/viewvc/llvm-project?rev=176250&view=rev

Thanks!

--kcc

>
>         Jakub