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


Thanks Carlos for your reply.

The prelink tool and method is working fine, but the required linking libraries can change during the product life cycle (explained detail in below).

In short (objective), attempting to reserve the VMA (00020000 - 22000000 ) for an application using linker script to avoid shared libraries fall in between these desired VMA.

The base address (first PT_LOAD VMA) of ld.so (0ffc0000) and libc (0fe40000) in my system is conflicting with application desired address which failed the application load (due to desired range not available).

 With respect to linker script :

 - Modified default PPC 32 linker script
 - Assigned application base address (first PT_LOAD) @ 28000000
 - Included required PHDR and assigned all sections according to PHDR
 - Included dummy section (for the desired address range)
 - Complied executable with modified linker script using -T <linker option
 - Created -Map to verified new section is properly included and allocation (desired size)

 While attempting to load the binary (custom linked) received failure message from dl-open.c

 "Inconsistency detected by ld.so: dl-open.c: 593: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)-r_state == RT_CONSISTENT' failed!"

 The above failure application was due to an attempt to open its own library with (RTLD_NOW | RTLD_LOCAL) option - This dlopen function is working fine without dummy section.

 So wondering the failure is only due to the included section or due to some open hold in dl-open code.

 I've also attempted below items:

 - Created application base address @ 0fe40000
             - Able to achieve the desired libraries memory layout (libraries after TASK_UNMAPPED_REGION)
             - But not able to use the desired VMA as executable is loaded in the same memory segment.

 - Prelinked all the required libs at desired location.
           - Worked fine.
           - Need to create dedicated rpath and need to wrap (in same bundle package) prelinked libs with application.
           - Hand work to pick the application required libs and manual verification to make sure there is no conflicts between the regions.
           - Application linking libraries can change during the product life cycle : Need to keep eye on this application always on watch list.

 - Attempted to allocate same way as like for huge TLB.
           - Failed with same inconsistency error message.

 Section Header:

   [24] .bss              NOBITS          28010d10 000d10 000008 00   WA  0   0  4
   [25] .dummy            NOBITS          00020000 010000 21FE0000 00   WA  0   0  4

 Program Header:

  LOAD           0x000000 0x28000000 0x28000000 0x00bc8 0x00bc8 R E 0x10000
  LOAD           0x000bc8 0x28010bc8 0x28010bc8 0x00148 0x00150 RW  0x10000
  LOAD           0x010000 0x00020000 0x00020000 0x00000 0x21FE0000     R E 0x10000


 Note: VMA (00020000 - 22000000 ) : Program File is mapped (mmap with MAP_FIXED option) later on process life cycle.


Thanks..
> 
> > Date: Mon, 6 May 2013 15:57:04 -0400
> > Subject: Re: Regarding "Inconsistency detected by ld.so" 32 Bit Elf
> > From: carlos@systemhalted.org
> > To: karthikeyan24s@hotmail.com
> > CC: libc-help@sourceware.org
> > 
> > On Mon, May 6, 2013 at 3:44 PM, Karthikeyan Shanmugam
> > <karthikeyan24s@hotmail.com> wrote:
> > > I tried certain things with prelink tool to relocate those libraries and able to successfully to relocate in expected place. But, I like to achieve the same thing using linker script tweak.
> > 
> > Why? If you have it working with prelink just use prelink.
> > 
> > Changes to the linker script won't guarantee the dynamic loader
> > doesn't load your application elsewhere.
> > 
> > The best ways to do what you want is via prelink, because the loader
> > is trying to honour the prelink.
> > 
> > Changing the linker script is fragile.
> > 
> > If you really want to change the linker script you'll need to post the
> > entire linker script for review.
> > 
> > Cheers,
> > Carlos. 		 	   		  

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