This is the mail archive of the
mailing list for the GCC project.
Re: libsanitizer merge from upstream r175042
On Fri, Feb 22, 2013 at 8:32 PM, Jakub Jelinek <firstname.lastname@example.org> 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,