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

[Karthikeyan Shanmugam]

Thanks again Carlos.

> On 05/07/2013 04:14 PM, Karthikeyan Shanmugam wrote:
> > The prelink tool and method is working fine, but the required linking
> > libraries can change during the product life cycle (explained detail
> > in below).
> 
> So you're trying, for reasons you can't or won't explain, to have a hole
> in the application memory space that you want to reserve for doing something.
> 

Yes, from linker script perspective I don't find any section/reason to create this hole.But this hole is created to make sure later process can use the same for mmap with MAP_FIXED.

> You should run `ld --verbose` and use that linker script as a starting point
> for *anything* that you do.

Yes. My changes are on top of default (ld --verbose command output script) script only. 
> 
> You're problem is too complex to talk about in generic, you need to put
> together a reduced test case that shows exactly what you're trying to do
> and exactly what fails.
> 
> 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.

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

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

Thanks in Advance.


> Date: Tue, 7 May 2013 16:29:38 -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/07/2013 04:14 PM, Karthikeyan Shanmugam wrote:
> > The prelink tool and method is working fine, but the required linking
> > libraries can change during the product life cycle (explained detail
> > in below).
> 
> So you're trying, for reasons you can't or won't explain, to have a hole
> in the application memory space that you want to reserve for doing something.
> 
> You should run `ld --verbose` and use that linker script as a starting point
> for *anything* that you do.
> 
> You're problem is too complex to talk about in generic, you need to put
> together a reduced test case that shows exactly what you're trying to do
> and exactly what fails.
> 
> 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.
> 
> Cheers,
> Carlos.
>