RE: Regarding "Inconsistency detected by ld.so" 32 Bit Elf

[Karthikeyan Shanmugam <karthikeyan24s at hotmail dot com>]

> On 05/08/2013 03:12 PM, Karthikeyan Shanmugam wrote:
> >> Please note that a reduced test case is ONE source file, ONE linker
> >> script, maybe ONE more source file to build a library with, and
> >> some instructions. It has to be simple enough for others on the
> >> list to try out and help you with. It would also be good if that
> >> test case works on x86-64 so others can help you.
> > 
> > I've one standalone program to reproduce this scenario compiled for
> > Power-PC. I'm currently not much familiar with INTEL arch, so will to
> > change the program a bit for Intel arch.
> > 

I'm facing difficulty in making INTEL arch based linker script for demo program. If PPC derived linker script and demo program is enough to represent the problem , please let me know.

> > In general, I thought similar kind of situation would have faced by
> > many others as because we have limited VMA in 32 bit chips to satisfy
> > contiguous memory allocations especially like database related
> > frameworks.
> 
> I know that QEMU has to do something similar. There are probably so
> few applications that need to do this that there is no good accepted
> standard way to accomplish this.

So do I need to approach/start separate forum or someone from this forum can help me on this item?
 
> Date: Wed, 8 May 2013 15:44:42 -0400
> From: carlos@redhat.com
> To: karthikeyan24s@hotmail.com
> CC: carlos@systemhalted.org; libc-help@sourceware.org
> Subject: Re: Regarding "Inconsistency detected by ld.so" 32 Bit Elf
> 
> On 05/08/2013 03:12 PM, Karthikeyan Shanmugam wrote:
> >> Please note that a reduced test case is ONE source file, ONE linker
> >> script, maybe ONE more source file to build a library with, and
> >> some instructions. It has to be simple enough for others on the
> >> list to try out and help you with. It would also be good if that
> >> test case works on x86-64 so others can help you.
> > 
> > I've one standalone program to reproduce this scenario compiled for
> > Power-PC. I'm currently not much familiar with INTEL arch, so will to
> > change the program a bit for Intel arch.
> > 
> > In general, I thought similar kind of situation would have faced by
> > many others as because we have limited VMA in 32 bit chips to satisfy
> > contiguous memory allocations especially like database related
> > frameworks.
> 
> I know that QEMU has to do something similar. There are probably so
> few applications that need to do this that there is no good accepted
> standard way to accomplish this.
> 
> > 1. Is there any other method to force all libs (including dynamic
> > loader) to fall above TASK_UNMAPPED_AREA area instead to be in
> > desired/fixed address (except prelink and libtool)?
> 
> I know of no other way than prelink.
> 
> How do you do this with libtool?
> 

I think using libtool will be able to tweak the TASK_UNMAPPED_REGION <-> lib but don't think will be able to relocate.

> > 2. In prelink tool, is there any auto option to detect-force relocate
> > only the non-zero PT_LOAD segment libraries?
> 
> I don't know.
> 

Any idea how to identify the end (possible/probable) address of a shared library like libc?. I'm asking this because I noticed different end address during periodic loading of a same application, so like to know the worst case memory (size) which will be used by shared library (libc or any).

Thanks.