Regarding "Inconsistency detected by ld.so"

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Regarding "Inconsistency detected by ld.so"

Sakthi
Hi All,

I'm currently facing one problem with respect to load a PPC32 Bit binary (linked against custom linker script), there is no issue with compilation and linking but facing below trouble in loading the binary. Please find the complete details as mentioned below.

root@localhost:/root/test> ./testsample
Inconsistency detected by ld.so: dl-open.c: 593: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!

In code we have dlopen call as like below.

fd = dlopen(libpath, RTLD_NOW | RTLD_LOCAL)

GDB Debug:
================

(gdb)
(gdb)
(gdb)  set stop-on-solib-events 1
(gdb) run
Starting program: /root/test/testsample
Stopped due to shared library event
(gdb) info shared
From        To          Syms Read   Shared Object Library
0x0ffc1f00  0x0ffd9e20  Yes (*)     /lib/ld.so.1
(*): Shared library is missing debugging information.
(gdb) c
Continuing.
Stopped due to shared library event
(gdb) info shared
From        To          Syms Read   Shared Object Library
0x0ffc1f00  0x0ffd9e20  Yes (*)     /lib/ld.so.1
0x2290fe20  0x22913200  Yes (*)     /usr/lib/libtestsampleloader.1.0.1.so
0x0fe5f160  0x0ff6d2a0  Yes (*)     /lib/libc.so.6
0x0fe20b80  0x0fe21fe0  Yes (*)     /lib/libdl.so.2
(*): Shared library is missing debugging information.
(gdb)
From        To          Syms Read   Shared Object Library
0x0ffc1f00  0x0ffd9e20  Yes (*)     /lib/ld.so.1
0x2290fe20  0x22913200  Yes (*)     /usr/lib/libtestsampleloader.1.0.1.so
0x0fe5f160  0x0ff6d2a0  Yes (*)     /lib/libc.so.6
0x0fe20b80  0x0fe21fe0  Yes (*)     /lib/libdl.so.2
(*): Shared library is missing debugging information.
(gdb) c
Continuing.
Begin testsample Session (pid 3744).
Inconsistency detected by ld.so: dl-open.c: 593: _dl_open: Assertion `_dl_debug_initialize (0, args.nsid)->r_state == RT_CONSISTENT' failed!

Program exited with code 0177.
(gdb) backtrace
No stack.
(gdb) info shared
From        To          Syms Read   Shared Object Library
0x0ffc1f00  0x0ffd9e20  Yes (*)     /lib/ld.so.1
(*): Shared library is missing debugging information.
(gdb) info all
The program has no registers now.
(gdb) quit

===================

This problem is happening only after include the below test section:
PHDR {
 <snip>
 tststart PT_LOAD;
}
SECTIONS {

  TSTSTART = 0x0f850000;
  .tststart TSTSTART : AT (TSTSTART)
  {
     *(.tststart)
  } :tststart
}

======================

Program Header Information:

Elf file type is EXEC (Executable file)
Entry point 0x250005c0
There are 9 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x25000034 0x25000034 0x00120 0x00120 R   0x4
  INTERP         0x000154 0x25000154 0x25000154 0x0000d 0x0000d R   0x1
      [Requesting program interpreter: /lib/ld.so.1]
  LOAD           0x000000 0x25000000 0x25000000 0x00af4 0x00af4 R E 0x10000
  LOAD           0x000af4 0x25010af4 0x25010af4 0x00134 0x0013c RW  0x10000
  DYNAMIC        0x000b10 0x25010b10 0x25010b10 0x00110 0x00110 RW  0x4
  NOTE           0x000a94 0x25000a94 0x25000a94 0x00020 0x00020 R   0x4
  GNU_EH_FRAME   0x000ab4 0x25000ab4 0x25000ab4 0x00014 0x00014 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
  GNU_EH_FRAME   0x000000 0x00000000 0x00000000 0x00000 0x00000 R   0x4

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .text .fini .rodata .note.ABI-tag .eh_frame_hdr .eh_frame
   03     .ctors .dtors .jcr .got2 .dynamic .got .plt .data .bss
   04     .dynamic .got .plt
   05     .note.ABI-tag
   06     .eh_frame_hdr
   07
   08
File command output:
ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.34, with unknown capability 0x41000000 = 0x13676e75, with unknown capability 0x10000 = 0xb0401, not stripped


Few Points:

- Running on 32 Bit multicore processor (processes is affined to one core)
- Compiled & Linked code for powerpc 32 Bit.
- powerpc-wrs-linux-gnu-gcc - 4.4.1
- GNU ld 2.19.51.20090709

Any suggestions or pointer will be helpful to continue my investigation.

Thanks in Advance.
Reply | Threaded
Open this post in threaded view
|

Re: Regarding "Inconsistency detected by ld.so"

Sakthi
Not sure this problem is due to the new test segment added in the linker script. tried with below command and shows ELF segment is not aligned properly.

root@localhost:/root/test> /lib/ld-2.11.1.so --list ./testsample
./testsample: error while loading shared libraries: ./testsample: ELF load command address/offset not properly aligned

...

After checking the below link, guess I'm into the same problem where I want to relocate the mapped libc and ld by creating an illusion in linker script that memory is mapped in the specific region.

http://sourceware.org/ml/libc-alpha/2012-02/msg00045.html


points:

By default libc and ld are mapped to x-y (which is not TASK_UNMAPPED) and now I've modified default linker script to add a new section (PT_LOAD) which is mapped between x-y

x address is aligned after setting the location counter.

. =x;
. = ALIGN (CONSTANT (MAXPAGESIZE)) - ((CONSTANT (MAXPAGESIZE) - .) & (CONSTANT (MAXPAGESIZE) - 1));

--
Any pointers ?

Thanks in Advance.
Reply | Threaded
Open this post in threaded view
|

Re: Regarding "Inconsistency detected by ld.so"

Sakthi

  PHDR           0x000034 0x25000034 0x25000034 0x00120 0x00120 R   0x4
  INTERP         0x000154 0x25000154 0x25000154 0x0000d 0x0000d R   0x1
      [Requesting program interpreter: /lib/ld.so.1]
  LOAD           0x000000 0x25000000 0x25000000 0x00af4 0x00af4 R E 0x10000
  LOAD           0x000af4 0x25010af4 0x25010af4 0x00134 0x0013c RW  0x10000
  LOAD           0x000c28 0x00000000 0x00000000 0x00000 0x00000     0x10000
  DYNAMIC        0x000b10 0x25010b10 0x25010b10 0x00110 0x00110 RW  0x4
  NOTE           0x000a94 0x25000a94 0x25000a94 0x00020 0x00020 R   0x4
  GNU_EH_FRAME   0x000ab4 0x25000ab4 0x25000ab4 0x00014 0x00014 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

Any idea why these addresses are zero ?

In linker script, I explicitly mentioned 0x0f000000 for this reserved PT_LOAD section, but somehow not reflecting in the program header?

Any pointers?
Reply | Threaded
Open this post in threaded view
|

Re: Regarding "Inconsistency detected by ld.so"

Alan Modra-3
On Tue, Apr 09, 2013 at 06:18:05AM -0700, Sakthi wrote:
> Any idea why these addresses are zero ?
>
> In linker script, I explicitly mentioned *0x0f000000 *for this reserved
> PT_LOAD section, but somehow not reflecting in the program header?

If you post a self-contained testcase demonstrating the problem you
might get some answers.  From what you've posted so far, I can't
even make wild guesses, sorry.

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: Regarding "Inconsistency detected by ld.so"

Sakthi
Hi Alan,

Thanks for your reply.

The output I've posted in above thread is from one legacy framework. I will create one sample test program to demonstrate the scenario.

In Short :

I've one standalone application (32 - Bit) for which need contiguous memory layout. Due to the shared libraries falling in a place (libc @0fe40000 and ld @0ffc0000) which blocks us from using contiguous memory.

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.

My assumption:

During process instantiation, When the dynamic loader seeks for the unmapped region there is no mmap in area 0x0f... which resulted in placing the shared libraries @0x0f...

By default PPC linker is using "-z combreloc" script. I've created one custom linker script on top of comroloc after adding a fack section @0x0f... which resulted in above "Inconsistency error"

Without fake section, custom linker script is working fine as expected.

...

Reply | Threaded
Open this post in threaded view
|

Re: Regarding "Inconsistency detected by ld.so"

Sakthi
Forgot to add that ASLR and other randomization is completely disabled (intentionally) in my system.
Reply | Threaded
Open this post in threaded view
|

Re: Regarding "Inconsistency detected by ld.so"

Alan Modra-3
In reply to this post by Sakthi
On Wed, Apr 10, 2013 at 01:48:32AM -0700, Sakthi wrote:
> In Short :
>
> I've one standalone application (32 - Bit) for which need contiguous memory
> layout. Due to the shared libraries falling in a place (libc @0fe40000 and
> ld @0ffc0000) which blocks us from using contiguous memory.
>
> 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.

OK, now I think I see what you're trying to do.  You're trying to
reserve the address space of interest in your (non-pie) executable,
and get a PT_LOAD header but haven't put any contents in your fake
section so get zeros for p_vaddr etc.  Try the following.

  TSTSTART = 0x0f850000;
  .tststart TSTSTART : ALIGN (0x10000)
  {
     . = 0x23456;
  } :tststart

Replace the 0x23456 with the length you need.

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: Regarding "Inconsistency detected by ld.so"

Sakthi
Hi Alan,

Thanks a lot for your reply.

I modified the fake are with your changes and could see the program header fake part holds valid VirtAddr now. But with new changes also not able to launch the executable and getting the below mentioned error message.

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

--------------

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x25000034 0x25000034 0x00120 0x00120 R   0x4
  INTERP         0x000154 0x25000154 0x25000154 0x0001a 0x0001a R   0x1
      [Requesting program interpreter: /root/prelink/lib/ld.so.1]
  LOAD           0x000000 0x25000000 0x25000000 0x00b34 0x00b34 R E 0x10000
  LOAD           0x000b34 0x25010b34 0x25010b34 0x0013c 0x00144 RW  0x10000
  LOAD           0x010000 0x0f850000 0x0f850000 0x00000 0x00010     0x10000
  DYNAMIC        0x000b50 0x25010b50 0x25010b50 0x00118 0x00118 RW  0x4
  NOTE           0x000ad4 0x25000ad4 0x25000ad4 0x00020 0x00020 R   0x4
  GNU_EH_FRAME   0x000af4 0x25000af4 0x25000af4 0x00014 0x00014 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

--------------

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        25000154 000154 00001a 00   A  0   0  1
  [ 2] .hash             HASH            25000170 000170 0000ac 04   A  3   0  4
  [ 3] .dynsym           DYNSYM          2500021c 00021c 000180 10   A  4   1  4
  [ 4] .dynstr           STRTAB          2500039c 00039c 000132 00   A  0   0  1
  [ 5] .gnu.version      VERSYM          250004ce 0004ce 000030 02   A  3   0  2
....
....
  [31] .debug_str        PROGBITS        00000000 000ddd 0000b1 01  MS  0   0  1
  [32] .tststart         NOBITS          0f850000 010000 000010 00  WA  0   0 65536
  [33] .shstrtab         STRTAB          00000000 000e8e 00013a 00      0   0  1
  [34] .symtab           SYMTAB          00000000 001568 000500 10     35  57  4
  [35] .strtab           STRTAB          00000000 001a68 0002a8 00      0   0  1

I thought the problem is with dynamic linker as the ld.so is reporting some problem, so tried with prelinked ld.so and --dynamic-linker option which not helped as expected.

Any idea?
Reply | Threaded
Open this post in threaded view
|

Re: Regarding "Inconsistency detected by ld.so"

Sakthi
Attempted to create a fake block between (00020000 - 0fffffff) with below section which resulted libdl to fall @0fe20000 and executable loading is failing with error message "Inconsistency detected by ld.so"
PHDR

TSTSTART PT_LOAD FLAGS (0);

  .TSTSTART 0x00020000: ALIGN (0x10000)
    {
    . = 0x0FFDFFFF;
  } :TSTSTART
Reply | Threaded
Open this post in threaded view
|

Re: Regarding "Inconsistency detected by ld.so"

Alan Modra-3
On Mon, Apr 29, 2013 at 09:33:19AM -0700, Sakthi wrote:
> Attempted to create a fake block between (00020000 - 0fffffff) with below
> section which resulted libdl to fall @0fe20000 and executable loading is
> failing with error message "Inconsistency detected by ld.so"

I don't know why this is happening.  You may be better off asking on
[hidden email].  ld.so isn't part of the binutils project.

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: Regarding "Inconsistency detected by ld.so"

Sakthi
Hi Alan,

Thanks...

I'll check with the provided community.

Meanwhile, I modified the executable start address to @0f850000 and could see the llibraries are properly relocated. But not sure why same thing is not happening when a fake section is created for the same virtual address region with a proper length.?

Also, in below program header output for a fake section I can see valid offset value. Is it expected?

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align

  LOAD           0x010000 0x0f850000 0x0f850000 0x00000 0x00010     0x10000

Thanks in Advance.