6.3: shared libs not really shared?

Hello,

I have my shared lib which is used by a couple of prgs. I took a look
into a mem consumption and the results are strange. When I run 2 copies
of the same prg it seems that my .so is loaded twice into the memory. It
happens only to my lib. Standard libs are loaded once (libcpp, libm) as
expected. And this happens on my embedded armle target. When I run the
same test on PC, my .so is loaded just once. Strange, isn’t it? The
problem becomes important when my libs take 20MB and I want 5 small prgs
using them. It fits into 32MB on PC, it doesn’t on ARM. Help please!
regards - WP

Wojciech Piechowski wrote:

Hello,

I have my shared lib which is used by a couple of prgs. I took a look
into a mem consumption and the results are strange. When I run 2 copies
of the same prg it seems that my .so is loaded twice into the memory. It
happens only to my lib. Standard libs are loaded once (libcpp, libm) as
expected. And this happens on my embedded armle target. When I run the
same test on PC, my .so is loaded just once. Strange, isn’t it? The
problem becomes important when my libs take 20MB and I want 5 small prgs
using them. It fits into 32MB on PC, it doesn’t on ARM. Help please!
regards - WP

Do an objdump -x and check if you’ve got a DT_TEXTREL set in your
dynamic section. Also, putting DL_DEBUG=1 in front of your app that
loads your lib should show if it is in fact loaded with private copies
of the text/code.

If this is the case, try building your lib without debug info to see if
the DT_TEXTREL/private load issue goes away.


Cheers,
Adam

QNX Software Systems
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

Adam Mallory napisa³(a):

Wojciech Piechowski wrote:

Hello,

I have my shared lib which is used by a couple of prgs. I took a look
into a mem consumption and the results are strange. When I run 2
copies of the same prg it seems that my .so is loaded twice into the
memory. It happens only to my lib. Standard libs are loaded once
(libcpp, libm) as expected. And this happens on my embedded armle
target. When I run the same test on PC, my .so is loaded just once.
Strange, isn’t it? The problem becomes important when my libs take
20MB and I want 5 small prgs using them. It fits into 32MB on PC, it
doesn’t on ARM. Help please! regards - WP


Do an objdump -x and check if you’ve got a DT_TEXTREL set in your
dynamic section. Also, putting DL_DEBUG=1 in front of your app that
loads your lib should show if it is in fact loaded with private copies
of the text/code.

If this is the case, try building your lib without debug info to see if
the DT_TEXTREL/private load issue goes away.

Thanks. Yes, it shows I have DT_TEXTREL in the dynamic section. Even
when compiled without debug info. I have no idea how to get rid of it. I
thought of trying gcc 3.3.1 (I’m using 2.95.2 now) but it spammed me
with “undefined reference to `__gxx_personality_sj0’” and many like this
so I’m fighting with 2.95.2 and can’t find any source of TEXTREL for now.

Wojciech Piechowski napisa³(a):

Adam Mallory napisa³(a):

Wojciech Piechowski wrote:

Hello,

I have my shared lib which is used by a couple of prgs. I took a look
into a mem consumption and the results are strange. When I run 2
copies of the same prg it seems that my .so is loaded twice into the
memory. It happens only to my lib. Standard libs are loaded once
(libcpp, libm) as expected. And this happens on my embedded armle
target. When I run the same test on PC, my .so is loaded just once.
Strange, isn’t it? The problem becomes important when my libs take
20MB and I want 5 small prgs using them. It fits into 32MB on PC, it
doesn’t on ARM. Help please! regards - WP



Do an objdump -x and check if you’ve got a DT_TEXTREL set in
your dynamic section. Also, putting DL_DEBUG=1 in front of your app
that loads your lib should show if it is in fact loaded with private
copies of the text/code.

If this is the case, try building your lib without debug info to see
if the DT_TEXTREL/private load issue goes away.


Thanks. Yes, it shows I have DT_TEXTREL in the dynamic section. Even
when compiled without debug info. I have no idea how to get rid of it. I
thought of trying gcc 3.3.1 (I’m using 2.95.2 now) but it spammed me
with “undefined reference to `__gxx_personality_sj0’” and many like this
so I’m fighting with 2.95.2 and can’t find any source of TEXTREL for now.

Some more info:
I took a look into my .o components of this .so. All of them are
compiled with -shared -fPIC -fpic, these options go to the linker as
well. All .text sections of the .o’s have CONTENTS, ALLOC, LOAD, RELOC,
READONLY, CODE attrs. objdump -x of one of these looks like this:

display.o: file format elf32-littlearm
display.o
architecture: arm, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags = 0: [APCS-32] [FPA float format]

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000008b8 00000000 00000000 00000034 22
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 0000007c 00000000 00000000 000008ec 2
2
CONTENTS, ALLOC, LOAD, RELOC, DATA
2 .bss 00000000 00000000 00000000 00000968 2**0
ALLOC
SYMBOL TABLE:
00000000 l df ABS 00000000 display.cc
00000001 l ABS 00000000 pic
00000001 l ABS 00000000 PIC
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l .text 00000000 gcc2_compiled.
00000018 l O .data 00000008 mutex.855
00000020 l O .data 0000005c __rcs_id
00000000 w O .data 00000004 __grmath_h_rcs_id
00000004 w O .data 00000004 __operation_h_rcs_id
00000008 w O .data 00000004 __display_point_h_rcs_id
0000000c w O .data 00000004 __display_rect_h_rcs_id
00000010 w O .data 00000004 __bitmap_h_rcs_id
00000014 w O .data 00000004 __display_h_rcs_id
00000228 g F .text 00000290 open__7displayiPc
00000000 UND 00000000 __builtin_vec_delete
00000000 UND 00000000 open
00000000 UND 00000000 devctl
00000000 UND 00000000 resize__7tBitmapRC6tPoint
00000000 UND 00000000 __builtin_vec_new
00000000 UND 00000000 clear__7tBitmapUc
00000810 g F .text 000000a8 setpalette__7displayPi
000004b8 g F .text 00000270 show__7displayR7tBitmap
00000000 UND 00000000 pthread_mutex_lock
00000000 UND 00000000 write
00000000 UND 00000000 pthread_mutex_unlock
00000000 UND 00000000 GLOBAL_OFFSET_TABLE
00000728 g F .text 00000034 close__7display
00000000 UND 00000000 close
0000075c g F .text 0000003c sync__7display
00000798 g F .text 0000003c setpower__7displayi
000007d4 g F .text 0000003c setcontrast__7displayi


RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000024c R_ARM_PC24 .text
00000250 R_ARM_PLT32 __builtin_vec_delete
00000270 R_ARM_PLT32 open
0000027c R_ARM_PC24 .text
00000288 R_ARM_PC24 .text
0000029c R_ARM_PLT32 devctl
000002ac R_ARM_PC24 .text
000002c8 R_ARM_PLT32 devctl
000002e8 R_ARM_PLT32 devctl
00000308 R_ARM_PLT32 devctl
00000328 R_ARM_PLT32 devctl
00000348 R_ARM_PLT32 devctl
00000364 R_ARM_PLT32 devctl
00000380 R_ARM_PLT32 devctl
000003a0 R_ARM_PLT32 devctl
000003bc R_ARM_PLT32 devctl
000003d8 R_ARM_PLT32 devctl
000003f8 R_ARM_PLT32 resize__7tBitmapRC6tPoint
00000428 R_ARM_PLT32 __builtin_vec_new
00000438 R_ARM_PLT32 clear__7tBitmapUc
00000478 R_ARM_PC24 .text
00000480 R_ARM_PLT32 setpalette__7displayPi
00000484 R_ARM_PC24 .text
000004e8 R_ARM_PLT32 pthread_mutex_lock
00000508 R_ARM_PC24 .text
00000528 R_ARM_PC24 .text
00000568 R_ARM_PC24 .text
00000588 R_ARM_PC24 .text
000005a8 R_ARM_PC24 .text
000005b0 R_ARM_PC24 .text
000005d0 R_ARM_PC24 .text
000005e4 R_ARM_PC24 .text
00000604 R_ARM_PC24 .text
00000614 R_ARM_PC24 .text
0000062c R_ARM_PC24 .text
0000064c R_ARM_PC24 .text
0000068c R_ARM_PC24 .text
000006ac R_ARM_PC24 .text
000006cc R_ARM_PC24 .text
000006d4 R_ARM_PC24 .text
000006f4 R_ARM_PLT32 devctl
00000704 R_ARM_PLT32 write
00000710 R_ARM_PLT32 pthread_mutex_unlock
00000714 R_ARM_PC24 .text
00000718 R_ARM_GOTPC GLOBAL_OFFSET_TABLE
0000071c R_ARM_GOT32 mutex.855
0000073c R_ARM_PLT32 close
00000748 R_ARM_PC24 .text
0000074c R_ARM_PLT32 __builtin_vec_delete
00000788 R_ARM_PLT32 devctl
0000078c R_ARM_PC24 .text
000007c4 R_ARM_PLT32 devctl
000007c8 R_ARM_PC24 .text
00000800 R_ARM_PLT32 devctl
00000804 R_ARM_PC24 .text
00000854 R_ARM_PC24 .text
0000088c R_ARM_PC24 .text
000008a8 R_ARM_PLT32 devctl
000008ac R_ARM_PC24 .text


RELOCATION RECORDS FOR [.data]:
OFFSET TYPE VALUE
00000000 R_ARM_ABS32 .text
00000004 R_ARM_ABS32 .text
00000008 R_ARM_ABS32 .text
0000000c R_ARM_ABS32 .text
00000010 R_ARM_ABS32 .text
00000014 R_ARM_ABS32 .text

It seems that -S passed to linker removes TEXTREL. And things started to
work. I just don’t know why. There was no debug info anyway. Even strip
didn’t change it.

Wojciech Piechowski napisa³(a):

Wojciech Piechowski napisa³(a):

Adam Mallory napisa³(a):

Wojciech Piechowski wrote:

Hello,

I have my shared lib which is used by a couple of prgs. I took a
look into a mem consumption and the results are strange. When I run
2 copies of the same prg it seems that my .so is loaded twice into
the memory. It happens only to my lib. Standard libs are loaded once
(libcpp, libm) as expected. And this happens on my embedded armle
target. When I run the same test on PC, my .so is loaded just once.
Strange, isn’t it? The problem becomes important when my libs take
20MB and I want 5 small prgs using them. It fits into 32MB on PC, it
doesn’t on ARM. Help please! regards - WP




Do an objdump -x and check if you’ve got a DT_TEXTREL set in
your dynamic section. Also, putting DL_DEBUG=1 in front of your app
that loads your lib should show if it is in fact loaded with private
copies of the text/code.

If this is the case, try building your lib without debug info to see
if the DT_TEXTREL/private load issue goes away.


Thanks. Yes, it shows I have DT_TEXTREL in the dynamic section. Even
when compiled without debug info. I have no idea how to get rid of it.
I thought of trying gcc 3.3.1 (I’m using 2.95.2 now) but it spammed me
with “undefined reference to `__gxx_personality_sj0’” and many like
this so I’m fighting with 2.95.2 and can’t find any source of TEXTREL
for now.


Some more info:
I took a look into my .o components of this .so. All of them are
compiled with -shared -fPIC -fpic, these options go to the linker as
well. All .text sections of the .o’s have CONTENTS, ALLOC, LOAD, RELOC,
READONLY, CODE attrs. objdump -x of one of these looks like this: