This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
RE: Regarding "Inconsistency detected by ld.so" 32 Bit Elf
- From: Karthikeyan Shanmugam <karthikeyan24s at hotmail dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Carlos O'Donell <carlos at systemhalted dot org>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Thu, 9 May 2013 23:05:27 +0530
- Subject: RE: Regarding "Inconsistency detected by ld.so" 32 Bit Elf
- References: <BLU166-W4365C811BA9EAD5EFFDFDACFB90 at phx dot gbl>,<CAE2sS1jvd97vkPVm+mG=7BBfXX6yYE7POaR75kufrETo40wZkw at mail dot gmail dot com>,<BLU166-W16249AA58CE03F785B384DCFBA0 at phx dot gbl> <BLU166-W3756E8E882E23498AF7DF8CFBA0 at phx dot gbl>,<51896432 dot 9010104 at redhat dot com> <BLU166-W44B5F09CC4E3CFCAE7567CCFBB0 at phx dot gbl>,<518AAB2A dot 7070104 at redhat 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.