This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
>>> 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?

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.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]