Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/Builds/Strange library loading issue (first posted in general)/List of Posts
Forum Topic - Strange library loading issue (first posted in general): (13 Items)
   
Update
Liam Howlett
11/13/2009 2:36 PM
post41956
Strange library loading issue (first posted in general)   
Hello,

I have been  having an issue with one of my processes loading one of my libraries that was included in my binary image 
by mkifs with compression 3.

The included library is a different size as the one still in the compiled directory.  There were no errors on make or 
mkifs.

The problem I see is this:

# export DL_DEBUG=1
# export LD_LIBRARY_PATH=/proc/boot
# ls -la /proc/boot/liboamlib.so.1
-rwxrwxr-x  1 508       508          446464 Nov 13  2009 /proc/boot/liboamlib.so.1

Process 352276 (ls) exited status=0.
# dbs
load_object: attempt load of liboamutilities.so.1
load_elf32: loaded lib at addr fe378000(text) fe38ac90(data)
load_object: attempt load of libcommonSlSwLogLib.so.1
load_elf32: loaded lib at addr fe38c000(text) fe39b500(data)
load_object: attempt load of libutilities.so.1
load_elf32: loaded lib at addr fe39d000(text) fe3b4740(data)
load_object: attempt load of liboamlib.so.1
load_elf32: mmaped, addr 0 67ca0 vaddr fe41eca0
Could not find library liboamlib.so.1

Process 360468 (dbs) exited status=1.
# export LD_LIBRARY_PATH=/tmp:/proc/boot
# ls -la /tmp/liboamlib.so.1
-rw-r--r--  2 root      0            549491 Nov 13  2009 /tmp/liboamlib.so.1

Process 376852 (ls) exited status=0.
# dbs
load_object: attempt load of liboamutilities.so.1
load_elf32: loaded lib at addr fe378000(text) fe38ac90(data)
load_object: attempt load of libcommonSlSwLogLib.so.1
load_elf32: loaded lib at addr fe38c000(text) fe39b500(data)
load_object: attempt load of libutilities.so.1
load_elf32: loaded lib at addr fe39d000(text) fe3b4740(data)
load_object: attempt load of liboamlib.so.1
load_elf32: loaded lib at addr fe3b6000(text) fe41dca0(data)
load_object: attempt load of liboamwaveready.so.1
load_elf32: loaded lib at addr fe424000(text) fe4dac30(data)
load_object: attempt load of libacilib.so.1
load_elf32: loaded lib at addr fe4e3000(text) fe4f0660(data)
load_object: attempt load of libcommonSlAppBaseLib.so.1
load_elf32: loaded lib at addr fe4f2000(text) fe509d40(data)
load_object: attempt load of libcommonRblPulseTimerLib.so.1
load_elf32: loaded lib at addr fe50b000(text) fe514690(data)
load_object: attempt load of libcommonRblUtilitiesLib.so.1
load_elf32: loaded lib at addr fe515000(text) fe523c30(data)
load_object: attempt load of libsocket.so.2
load_elf32: loaded lib at addr fe525000(text) fe545a60(data)
load_object: attempt load of libm.so.2
load_elf32: loaded lib at addr fe550000(text) fe56edb0(data)
load_object: attempt load of libham.so.2
load_elf32: loaded lib at addr fe573000(text) fe57ce80(data)
load_object: attempt load of libecpp-ne.so.4
load_elf32: loaded lib at addr fe57e000(text) fe59b780(data)


As you can see, the file in /tmp works much better than the one in /proc/boot.

I am cross compiling from x86 linux to ppc QNX 6.3.2.  Our build environment is not trivial to further complicate the 
issue.

Why are the libraries different sizes?
Could whatever changed the size of the lib cause this issue?
Is there anything else that could cause the issue?

Thanks,
Liam
Colin Burgess(deleted)
11/13/2009 2:48 PM
post41958
Re: Strange library loading issue (first posted in general)   
The lib in /proc/boot appears to be corrupted.  What does readelf -l /proc/boot/liboamlib.so.1 show?

Liam Howlett wrote:
> Hello,
> 
> I have been  having an issue with one of my processes loading one of my libraries that was included in my binary image
 by mkifs with compression 3.
> 
> The included library is a different size as the one still in the compiled directory.  There were no errors on make or 
mkifs.
> 
> The problem I see is this:
> 
> # export DL_DEBUG=1
> # export LD_LIBRARY_PATH=/proc/boot
> # ls -la /proc/boot/liboamlib.so.1
> -rwxrwxr-x  1 508       508          446464 Nov 13  2009 /proc/boot/liboamlib.so.1
> 
> Process 352276 (ls) exited status=0.
> # dbs
> load_object: attempt load of liboamutilities.so.1
> load_elf32: loaded lib at addr fe378000(text) fe38ac90(data)
> load_object: attempt load of libcommonSlSwLogLib.so.1
> load_elf32: loaded lib at addr fe38c000(text) fe39b500(data)
> load_object: attempt load of libutilities.so.1
> load_elf32: loaded lib at addr fe39d000(text) fe3b4740(data)
> load_object: attempt load of liboamlib.so.1
> load_elf32: mmaped, addr 0 67ca0 vaddr fe41eca0
> Could not find library liboamlib.so.1
> 
> Process 360468 (dbs) exited status=1.
> # export LD_LIBRARY_PATH=/tmp:/proc/boot
> # ls -la /tmp/liboamlib.so.1
> -rw-r--r--  2 root      0            549491 Nov 13  2009 /tmp/liboamlib.so.1
> 
> Process 376852 (ls) exited status=0.
> # dbs
> load_object: attempt load of liboamutilities.so.1
> load_elf32: loaded lib at addr fe378000(text) fe38ac90(data)
> load_object: attempt load of libcommonSlSwLogLib.so.1
> load_elf32: loaded lib at addr fe38c000(text) fe39b500(data)
> load_object: attempt load of libutilities.so.1
> load_elf32: loaded lib at addr fe39d000(text) fe3b4740(data)
> load_object: attempt load of liboamlib.so.1
> load_elf32: loaded lib at addr fe3b6000(text) fe41dca0(data)
> load_object: attempt load of liboamwaveready.so.1
> load_elf32: loaded lib at addr fe424000(text) fe4dac30(data)
> load_object: attempt load of libacilib.so.1
> load_elf32: loaded lib at addr fe4e3000(text) fe4f0660(data)
> load_object: attempt load of libcommonSlAppBaseLib.so.1
> load_elf32: loaded lib at addr fe4f2000(text) fe509d40(data)
> load_object: attempt load of libcommonRblPulseTimerLib.so.1
> load_elf32: loaded lib at addr fe50b000(text) fe514690(data)
> load_object: attempt load of libcommonRblUtilitiesLib.so.1
> load_elf32: loaded lib at addr fe515000(text) fe523c30(data)
> load_object: attempt load of libsocket.so.2
> load_elf32: loaded lib at addr fe525000(text) fe545a60(data)
> load_object: attempt load of libm.so.2
> load_elf32: loaded lib at addr fe550000(text) fe56edb0(data)
> load_object: attempt load of libham.so.2
> load_elf32: loaded lib at addr fe573000(text) fe57ce80(data)
> load_object: attempt load of libecpp-ne.so.4
> load_elf32: loaded lib at addr fe57e000(text) fe59b780(data)
> 
> 
> As you can see, the file in /tmp works much better than the one in /proc/boot.
> 
> I am cross compiling from x86 linux to ppc QNX 6.3.2.  Our build environment is not trivial to further complicate the 
issue.
> 
> Why are the libraries different sizes?
> Could whatever changed the size of the lib cause this issue?
> Is there anything else that could cause the issue?
> 
> Thanks,
> Liam
> 
> 
> 
> 
> 
> _______________________________________________
> 
> Builds
> http://community.qnx.com/sf/go/post41956
> 

-- 
cburgess@qnx.com
Liam Howlett
11/13/2009 2:57 PM
post41960
Re: Strange library loading issue (first posted in general)   
It does look that way, but I can't figure out how it happened (if it is the case)

$ ntoppc-readelf -l liboamlib.so.1

Elf file type is DYN (Shared object file)
Entry point 0x203c4
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00aa4000 0x66ca0 0x66ca0 R E 0x1000
  LOAD           0x066ca0 0x00067ca0 0x00b0aca0 0x04884 0x06360 RWE 0x1000
  DYNAMIC        0x06adbc 0x0006bdbc 0x0006bdbc 0x000d0 0x000d0 RW  0x4
  NOTE           0x066ca0 0x00066ca0 0x00066ca0 0x00000 0x00000 R   0x10


Thanks,
Liam
Colin Burgess(deleted)
11/13/2009 3:21 PM
post41964
Re: Strange library loading issue (first posted in general)   
That doesn't look so bad.  The size difference is because mkxfs stripps the section
info etc etc from the elf binary.

But the headers below show that the file is at least STORED as being the right size.
Try including the lib with the [+raw] option in the ifs.  If it still fails, do a cksum
of the /proc/boot version and the /tmp versions.

Could it be that the image is too large, and this is the last file, or something crazy like that?

Liam Howlett wrote:
> It does look that way, but I can't figure out how it happened (if it is the case)
> 
> $ ntoppc-readelf -l liboamlib.so.1
> 
> Elf file type is DYN (Shared object file)
> Entry point 0x203c4
> There are 4 program headers, starting at offset 52
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD           0x000000 0x00000000 0x00aa4000 0x66ca0 0x66ca0 R E 0x1000
>   LOAD           0x066ca0 0x00067ca0 0x00b0aca0 0x04884 0x06360 RWE 0x1000
>   DYNAMIC        0x06adbc 0x0006bdbc 0x0006bdbc 0x000d0 0x000d0 RW  0x4
>   NOTE           0x066ca0 0x00066ca0 0x00066ca0 0x00000 0x00000 R   0x10
> 
> 
> Thanks,
> Liam
> 
> 
> 
> _______________________________________________
> 
> Builds
> http://community.qnx.com/sf/go/post41960
> 

-- 
cburgess@qnx.com
Liam Howlett
11/13/2009 3:47 PM
post41971
Re: Strange library loading issue (first posted in general)   
> That doesn't look so bad.  The size difference is because mkxfs stripps the 
> section
> info etc etc from the elf binary.
> 
> But the headers below show that the file is at least STORED as being the right
>  size.
> Try including the lib with the [+raw] option in the ifs.  If it still fails, 
> do a cksum
> of the /proc/boot version and the /tmp versions.

Okay, that worked.  I ended up working around my build system though.  We generally create .so's and let mkifs link .so 
to .so.1.  With raw, that doesn't happen.. so I had to create one and edit by hand to test.

> 
> Could it be that the image is too large, and this is the last file, or 
> something crazy like that?
> 

No, we search the project for libraries and bins to include them.  oamlib ends up somewhere in the middle.

I guess this means mkifs is striping too much?

Thanks,
Liam
Liam Howlett
11/13/2009 3:57 PM
post41973
Re: Strange library loading issue (first posted in general)   
Actually mkifs says  that I should not use +raw for shared objects:

"Don't specify the +raw attribute for shared objects; it prevents them from being shared."

So any ideas on how to proceed?
Colin Burgess(deleted)
11/13/2009 3:59 PM
post41974
Re: Strange library loading issue (first posted in general)   
Hmmm, was the readelf you posted of the 'bad' version or the 'good' version?

Liam Howlett wrote:
> Actually mkifs says  that I should not use +raw for shared objects:
> 
> "Don't specify the +raw attribute for shared objects; it prevents them from being shared."
> 
> So any ideas on how to proceed?
> 
> 
> 
> _______________________________________________
> 
> Builds
> http://community.qnx.com/sf/go/post41973
> 

-- 
cburgess@qnx.com
Liam Howlett
11/13/2009 4:01 PM
post41975
Re: Strange library loading issue (first posted in general)   
the "bad" version.  The one located in /proc/boot that caused the process to not run.
Liam Howlett
11/16/2009 12:42 PM
post42031
Re: Strange library loading issue (first posted in general)   
Would permissions in the buildifs file cause how the stripping of symbols occurs from the mkifs command?

I'm trying to figure out why the library would be stripped incorrectly.
Colin Burgess(deleted)
11/16/2009 1:06 PM
post42035
Re: Strange library loading issue (first posted in general)   
Could you possible send me the original library, and then the library as stripped by mkifs.
You can extract the lib from the image with dumpifs

Cheers,

Colin

Liam Howlett wrote:
> Would permissions in the buildifs file cause how the stripping of symbols occurs from the mkifs command?
> 
> I'm trying to figure out why the library would be stripped incorrectly.
> 
> 
> 
> 
> _______________________________________________
> 
> Builds
> http://community.qnx.com/sf/go/post42031
> 

-- 
cburgess@qnx.com
Liam Howlett
11/16/2009 2:27 PM
post42039
Re: Strange library loading issue (first posted in general)   
Okay, they are sent to your email address.
Liam Howlett
11/17/2009 10:49 AM
post42091
Re: Strange library loading issue (first posted in general)   
Looking at the headers, there is a difference between the stripped and orig library.



$ ntoppc-readelf -l liboamlib.so.orig

Elf file type is DYN (Shared object file)
Entry point 0x203c4
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x66ca0 0x66ca0 R E 0x1000
  LOAD           0x066ca0 0x00067ca0 0x00067ca0 0x04884 0x06360 RWE 0x1000
  DYNAMIC        0x06adbc 0x0006bdbc 0x0006bdbc 0x000d0 0x000d0 RW  0x4
  NOTE           0x066ca0 0x00066ca0 0x00066ca0 0x00000 0x00000 R   0x10

 Section to Segment mapping:
  Segment Sections...
   00     .hash .dynsym .dynstr .gnu.version .gnu.version_d .rela.data .rela.fixup .rela.gnu.linkonce.s._ZTISt9streambuf
 .rela.gnu.linkonce.s._ZTI20CIdNameLookupFunctor .rela.gnu.linkonce.s._ZTI16CManagementModel .rela.gnu.linkonce.s.
_ZTI22CMOAttributeDescriptor .rela.gnu.linkonce.s._ZTI15CTypeDescriptor .rela.gnu.linkonce.s._ZTI9CCallback .rela.gnu.
linkonce.s._ZTIN3app15CXAciProtocolIfE .rela.gnu.linkonce.s._ZTI21CLightManagementModel .rela.got .rela.ctors .rela.
dtors .rela.plt .rela.sdata .text .init .fini .rodata .gnu.linkonce.s._ZTSSt3ios .gnu.linkonce.s._ZTS6CDbmIf .gnu.
linkonce.s._ZTS3CDn
   01     .data .gnu.linkonce.s._ZTISt9streambuf .gnu.linkonce.s.
_ZN15SingletonHolderI28COamAttributeIdLookupFunctor14CreateUsingNewE10mpInstanceE .gnu.linkonce.s.
_ZTI20CIdNameLookupFunctor .gnu.linkonce.s._ZTI16CManagementModel .gnu.linkonce.s._ZTI22CMOAttributeDescriptor .gnu.
linkonce.s._ZTI15CTypeDescriptor .gnu.linkonce.s._ZTI9CCallback .gnu.linkonce.s.
_ZN15SingletonHolderI12CSyncHandler14CreateUsingNewE10mpInstanceE .gnu.linkonce.s._ZTIN3app15CXAciProtocolIfE .gnu.
linkonce.s._ZN15SingletonHolderI30CGeneratedLightManagementModel14CreateUsingNewE10mpInstanceE .gnu.linkonce.s.
_ZN15SingletonHolderI25CGeneratedManagementModel14CreateUsingNewE10mpInstanceE .gnu.linkonce.s.
_ZTI21CLightManagementModel .dynamic .ctors .dtors .fixup .got .sdata .sbss .plt .bss
   02     .dynamic
   03



And


$ ntoppc-readelf -l liboamlib.so.stripped

Elf file type is DYN (Shared object file)
Entry point 0x203c4
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00a8d000 0x66ca0 0x66ca0 R E 0x1000
  LOAD           0x066ca0 0x00067ca0 0x00af3ca0 0x04884 0x06360 RWE 0x1000
  DYNAMIC        0x06adbc 0x0006bdbc 0x0006bdbc 0x000d0 0x000d0 RW  0x4
  NULL           0x066ca0 0x00066ca0 0x00066ca0 0x00000 0x00000 R   0x10


Notice the orig has the first line:
LOAD           0x000000 0x00000000 0x00000000 0x66ca0 0x66ca0 R E 0x1000

The stripped reads:
LOAD           0x000000 0x00000000 0x00a8d000 0x66ca0 0x66ca0 R E 0x1000

Is it normal for the stripped header to have a PhysAddr different than the orig?
Colin Burgess(deleted)
11/17/2009 11:21 AM
post42094
Re: Strange library loading issue (first posted in general)   
Yes.  One of the things mkxfs does is manipulate the physaddr field (that's how it does the
use-in-place stuff).

Liam Howlett wrote:
> Looking at the headers, there is a difference between the stripped and orig library.
> 
> 
> 
> $ ntoppc-readelf -l liboamlib.so.orig
> 
> Elf file type is DYN (Shared object file)
> Entry point 0x203c4
> There are 4 program headers, starting at offset 52
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD           0x000000 0x00000000 0x00000000 0x66ca0 0x66ca0 R E 0x1000
>   LOAD           0x066ca0 0x00067ca0 0x00067ca0 0x04884 0x06360 RWE 0x1000
>   DYNAMIC        0x06adbc 0x0006bdbc 0x0006bdbc 0x000d0 0x000d0 RW  0x4
>   NOTE           0x066ca0 0x00066ca0 0x00066ca0 0x00000 0x00000 R   0x10
> 
>  Section to Segment mapping:
>   Segment Sections...
>    00     .hash .dynsym .dynstr .gnu.version .gnu.version_d .rela.data .rela.fixup .rela.gnu.linkonce.s.
_ZTISt9streambuf .rela.gnu.linkonce.s._ZTI20CIdNameLookupFunctor .rela.gnu.linkonce.s._ZTI16CManagementModel .rela.gnu.
linkonce.s._ZTI22CMOAttributeDescriptor .rela.gnu.linkonce.s._ZTI15CTypeDescriptor .rela.gnu.linkonce.s._ZTI9CCallback .
rela.gnu.linkonce.s._ZTIN3app15CXAciProtocolIfE .rela.gnu.linkonce.s._ZTI21CLightManagementModel .rela.got .rela.ctors .
rela.dtors .rela.plt .rela.sdata .text .init .fini .rodata .gnu.linkonce.s._ZTSSt3ios .gnu.linkonce.s._ZTS6CDbmIf .gnu.
linkonce.s._ZTS3CDn
>    01     .data .gnu.linkonce.s._ZTISt9streambuf .gnu.linkonce.s.
_ZN15SingletonHolderI28COamAttributeIdLookupFunctor14CreateUsingNewE10mpInstanceE .gnu.linkonce.s.
_ZTI20CIdNameLookupFunctor .gnu.linkonce.s._ZTI16CManagementModel .gnu.linkonce.s._ZTI22CMOAttributeDescriptor .gnu.
linkonce.s._ZTI15CTypeDescriptor .gnu.linkonce.s._ZTI9CCallback .gnu.linkonce.s.
_ZN15SingletonHolderI12CSyncHandler14CreateUsingNewE10mpInstanceE .gnu.linkonce.s._ZTIN3app15CXAciProtocolIfE .gnu.
linkonce.s._ZN15SingletonHolderI30CGeneratedLightManagementModel14CreateUsingNewE10mpInstanceE .gnu.linkonce.s.
_ZN15SingletonHolderI25CGeneratedManagementModel14CreateUsingNewE10mpInstanceE .gnu.linkonce.s.
_ZTI21CLightManagementModel .dynamic .ctors .dtors .fixup .got .sdata .sbss .plt .bss
>    02     .dynamic
>    03
> 
> 
> 
> And
> 
> 
> $ ntoppc-readelf -l liboamlib.so.stripped
> 
> Elf file type is DYN (Shared object file)
> Entry point 0x203c4
> There are 4 program headers, starting at offset 52
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD           0x000000 0x00000000 0x00a8d000 0x66ca0 0x66ca0 R E 0x1000
>   LOAD           0x066ca0 0x00067ca0 0x00af3ca0 0x04884 0x06360 RWE 0x1000
>   DYNAMIC        0x06adbc 0x0006bdbc 0x0006bdbc 0x000d0 0x000d0 RW  0x4
>   NULL           0x066ca0 0x00066ca0 0x00066ca0 0x00000 0x00000 R   0x10
> 
> 
> Notice the orig has the first line:
> LOAD           0x000000 0x00000000 0x00000000 0x66ca0 0x66ca0 R E 0x1000
> 
> The stripped reads:
> LOAD           0x000000 0x00000000 0x00a8d000 0x66ca0 0x66ca0 R E 0x1000
> 
> Is it normal for the stripped header to have a PhysAddr different than the orig?
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 
> Builds
> http://community.qnx.com/sf/go/post42091
> 

-- 
cburgess@qnx.com

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems