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 systemhalted dot org>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Wed, 8 May 2013 01:44:25 +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>
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.