This is the mail archive of the
mailing list for the glibc project.
Re: Regarding "Inconsistency detected by ld.so" 32 Bit Elf
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Karthikeyan Shanmugam <karthikeyan24s at hotmail 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, 09 May 2013 14:40:36 -0400
- 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> <BLU166-W52EE351DA2F5FBA91E2223CFA40 at phx dot gbl>
On 05/09/2013 01:35 PM, Karthikeyan Shanmugam wrote:
>> 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.
It is a problem. Less people will be able to help you if you can't
duplicate the problem on a common architecture. There is nothing
target dependent about this problem. You should equally be able to
produce an example program that shows the problem on x86-64.
>>> In general, I thought similar kind of situation would have faced by
>>> many others as because Only the kernel knows.we have limited VMA in 32 bit chips to satisfy
>>> contiguous memory allocations especially like database related
>> 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?
That's up to you to decide. You can reach out to the QEMU developers
and ask them how they solved the problem. You should probably download
the QEMU code and review their solution.
>>> 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.
I don't believe that is true.
The only value I know of is TASK_UNMAPPED_BASE and it's a value used
by the Linux kernel users to determine where to start looking for
unused VM space to fill mmap requests.
I know of no coordination between userspace and the kernel that
ensures any control over TASK_UNMAPPED_BASE.
>>> 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.
Let me be clear here on two points.
I don't know what you mean by "detect-frce relocate."
I also don't know what you mean by "non-zero PT_LOAD segment libraries."
> 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).
The size is always known. Look at the size of the loadable segments,
and round up to page sizes and appropriate alignment.
The location is not known, the kernel decides that.