Core dump when using shared libraries

QNX Newsgroups (Archives) qdn.public.qnxrtp.porting
1

I have a problem with porting qt-x11-free-3.0.2 when building it with shared
libraries. If I build with QT as static library (libqt-mt.a) then everything
works fine. But if I use QT as shared library (libqt-mt.so) then I get core
dump before the program reach main(). Following is an example of a back
trace:

Program terminated with signal 11, segmentation violation.
#0 0xb032b2db in ?? ()
(gdb) bt
#0 0xb032b2db in ?? ()
#1 0xb032b42b in ?? ()
#2 0xb032a363 in ?? ()

Here is the objdump -x [myapp] | grep NEEDED

NEEDED libsocket.so.2
NEEDED libqt-mt.so.3
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

Here is the objdump -x libqt-mt.so

objdump -x libqt-mt.so| grep NEEDED

NEEDED libsocket.so.2
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

I have libqt-mt.so linked to libqt-mt-so.3.0.2 and libqt-mt.so.3 linked to
libqt-mt.so.3.0.2

Any clues???

2

Almost certainly you are not passing -shared (or -fpic) when compiling
the objects. Check your compile flags.

Cheers,

Colin

Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:

I have a problem with porting qt-x11-free-3.0.2 when building it with shared
libraries. If I build with QT as static library (libqt-mt.a) then everything
works fine. But if I use QT as shared library (libqt-mt.so) then I get core
dump before the program reach main(). Following is an example of a back
trace:

Program terminated with signal 11, segmentation violation.
#0 0xb032b2db in ?? ()
(gdb) bt
#0 0xb032b2db in ?? ()
#1 0xb032b42b in ?? ()
#2 0xb032a363 in ?? ()

Here is the objdump -x [myapp] | grep NEEDED

NEEDED libsocket.so.2
NEEDED libqt-mt.so.3
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

Here is the objdump -x libqt-mt.so

objdump -x libqt-mt.so| grep NEEDED

NEEDED libsocket.so.2
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

I have libqt-mt.so linked to libqt-mt-so.3.0.2 and libqt-mt.so.3 linked to
libqt-mt.so.3.0.2

Any clues???



–
cburgess@qnx.com

3

Do you mean when I am compiling my application which uses the shared library
or when I am generating the shared library?

Thanks
Jens

“Colin Burgess” <cburgess@qnx.com> wrote in message
news:a7m6t1$t0n$1@nntp.qnx.com…

Almost certainly you are not passing -shared (or -fpic) when compiling
the objects. Check your compile flags.

Cheers,

Colin

Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
I have a problem with porting qt-x11-free-3.0.2 when building it with
shared
libraries. If I build with QT as static library (libqt-mt.a) then
everything
works fine. But if I use QT as shared library (libqt-mt.so) then I get
core
dump before the program reach main(). Following is an example of a back
trace:

Program terminated with signal 11, segmentation violation.
#0 0xb032b2db in ?? ()
(gdb) bt
#0 0xb032b2db in ?? ()
#1 0xb032b42b in ?? ()
#2 0xb032a363 in ?? ()

Here is the objdump -x [myapp] | grep NEEDED

NEEDED libsocket.so.2
NEEDED libqt-mt.so.3
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

Here is the objdump -x libqt-mt.so

objdump -x libqt-mt.so| grep NEEDED

NEEDED libsocket.so.2
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

I have libqt-mt.so linked to libqt-mt-so.3.0.2 and libqt-mt.so.3 linked
to
libqt-mt.so.3.0.2

Any clues???





\

cburgess@qnx.com

4

Have you tried to create a Makefile using qmake for your testapp?
Using it should create a perfect Makefile for an app using qt.

Joerg


“Jens H Jorgensen” <jhj@remove-nospam-videk.com> schrieb im Newsbeitrag
news:a7na7c$85d$1@inn.qnx.com…

Do you mean when I am compiling my application which uses the shared
library
or when I am generating the shared library?

Thanks
Jens

“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:a7m6t1$t0n$> 1@nntp.qnx.com> …
Almost certainly you are not passing -shared (or -fpic) when compiling
the objects. Check your compile flags.

Cheers,

Colin

Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
I have a problem with porting qt-x11-free-3.0.2 when building it with
shared
libraries. If I build with QT as static library (libqt-mt.a) then
everything
works fine. But if I use QT as shared library (libqt-mt.so) then I get
core
dump before the program reach main(). Following is an example of a
back
trace:

Program terminated with signal 11, segmentation violation.
#0 0xb032b2db in ?? ()
(gdb) bt
#0 0xb032b2db in ?? ()
#1 0xb032b42b in ?? ()
#2 0xb032a363 in ?? ()

Here is the objdump -x [myapp] | grep NEEDED

NEEDED libsocket.so.2
NEEDED libqt-mt.so.3
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

Here is the objdump -x libqt-mt.so

objdump -x libqt-mt.so| grep NEEDED

NEEDED libsocket.so.2
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

I have libqt-mt.so linked to libqt-mt-so.3.0.2 and libqt-mt.so.3
linked
to
libqt-mt.so.3.0.2

Any clues???





\

cburgess@qnx.com

5

Yes - I am using qmake to generate first a project file and then a Makefile.

I think the answer to my previous question is that it the -shared option
must be used when generating the shared library file - true???

Jens
“Joerg Scherer” <joerg.schererNOSPAM@am3.com> wrote in message
news:a7nhjl$dpg$1@inn.qnx.com…

Have you tried to create a Makefile using qmake for your testapp?
Using it should create a perfect Makefile for an app using qt.

Joerg


“Jens H Jorgensen” <> jhj@remove-nospam-videk.com> > schrieb im Newsbeitrag
news:a7na7c$85d$> 1@inn.qnx.com> …
Do you mean when I am compiling my application which uses the shared
library
or when I am generating the shared library?

Thanks
Jens

“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:a7m6t1$t0n$> 1@nntp.qnx.com> …
Almost certainly you are not passing -shared (or -fpic) when compiling
the objects. Check your compile flags.

Cheers,

Colin

Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
I have a problem with porting qt-x11-free-3.0.2 when building it
with
shared
libraries. If I build with QT as static library (libqt-mt.a) then
everything
works fine. But if I use QT as shared library (libqt-mt.so) then I
get
core
dump before the program reach main(). Following is an example of a
back
trace:

Program terminated with signal 11, segmentation violation.
#0 0xb032b2db in ?? ()
(gdb) bt
#0 0xb032b2db in ?? ()
#1 0xb032b42b in ?? ()
#2 0xb032a363 in ?? ()

Here is the objdump -x [myapp] | grep NEEDED

NEEDED libsocket.so.2
NEEDED libqt-mt.so.3
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

Here is the objdump -x libqt-mt.so

objdump -x libqt-mt.so| grep NEEDED

NEEDED libsocket.so.2
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

I have libqt-mt.so linked to libqt-mt-so.3.0.2 and libqt-mt.so.3
linked
to
libqt-mt.so.3.0.2

Any clues???





\

cburgess@qnx.com
\

6

No that is not it. I verified that g++ is called with -shared during linking
of libqt-mt.so.3.0.2 and it still dumps core.

Any other suggestions?

Jens


“Colin Burgess” <cburgess@qnx.com> wrote in message
news:a7m6t1$t0n$1@nntp.qnx.com…

Almost certainly you are not passing -shared (or -fpic) when compiling
the objects. Check your compile flags.

Cheers,

Colin

Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
I have a problem with porting qt-x11-free-3.0.2 when building it with
shared
libraries. If I build with QT as static library (libqt-mt.a) then
everything
works fine. But if I use QT as shared library (libqt-mt.so) then I get
core
dump before the program reach main(). Following is an example of a back
trace:

Program terminated with signal 11, segmentation violation.
#0 0xb032b2db in ?? ()
(gdb) bt
#0 0xb032b2db in ?? ()
#1 0xb032b42b in ?? ()
#2 0xb032a363 in ?? ()

Here is the objdump -x [myapp] | grep NEEDED

NEEDED libsocket.so.2
NEEDED libqt-mt.so.3
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

Here is the objdump -x libqt-mt.so

objdump -x libqt-mt.so| grep NEEDED

NEEDED libsocket.so.2
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

I have libqt-mt.so linked to libqt-mt-so.3.0.2 and libqt-mt.so.3 linked
to
libqt-mt.so.3.0.2

Any clues???





\

cburgess@qnx.com

7

Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:

Yes - I am using qmake to generate first a project file and then a Makefile.

I think the answer to my previous question is that it the -shared option
must be used when generating the shared library file - true???

And, more importantly, all the .o’s that are linked into the shared library.

chris

\

Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

8

Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:

No that is not it. I verified that g++ is called with -shared during linking
of libqt-mt.so.3.0.2 and it still dumps core.

Any other suggestions?

First - you need to make sure the .o’s are built that way as well. Also,
I am not sure if -shared is enough for g++ or if -fPIC is also needed. You
could use qcc instead of g++.

chris

\

Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

9

It will not compile with qcc.

I just tried again and verified (cleaned out all .o files and did a rebuild)
that all .o files are compiled with both -shared and -fPIC and the .so file
is also generated with -shared and -fPIC - still the same problem core dump.

Is there anything I can analyse with objdump?

What if I compile with -g will that give me any more information?

What about those addresses that gdb bt gives me - do they tell me anything
about where the problem is?

If I do gdb [myapp] and then a run from within gdb - it core dumps and exits
gdb. Is is supposed to exit gdb?

Thanks
Jens


“Chris McKillop” <cdm@qnx.com> wrote in message
news:a7nup0$9mj$2@nntp.qnx.com…

Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
No that is not it. I verified that g++ is called with -shared during
linking
of libqt-mt.so.3.0.2 and it still dumps core.

Any other suggestions?


First - you need to make sure the .o’s are built that way as well. Also,
I am not sure if -shared is enough for g++ or if -fPIC is also needed.
You
could use qcc instead of g++.

chris

\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

10

Just tested it with debug turned on - no luck the gdb bt shows:

(gdb) bt
#0 0xb032b2db in ?? ()
#1 0xb032b42b in ?? ()
#2 0xb032a363 in ?? ()
(gdb)

–
Jens

“Jens H Jorgensen” <jhj@remove-nospam-videk.com> wrote in message
news:a7objh$30q$1@inn.qnx.com…

It will not compile with qcc.

I just tried again and verified (cleaned out all .o files and did a
rebuild)
that all .o files are compiled with both -shared and -fPIC and the .so
file
is also generated with -shared and -fPIC - still the same problem core
dump.

Is there anything I can analyse with objdump?

What if I compile with -g will that give me any more information?

What about those addresses that gdb bt gives me - do they tell me anything
about where the problem is?

If I do gdb [myapp] and then a run from within gdb - it core dumps and
exits
gdb. Is is supposed to exit gdb?

Thanks
Jens


“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:a7nup0$9mj$> 2@nntp.qnx.com> …
Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
No that is not it. I verified that g++ is called with -shared during
linking
of libqt-mt.so.3.0.2 and it still dumps core.

Any other suggestions?


First - you need to make sure the .o’s are built that way as well.
Also,
I am not sure if -shared is enough for g++ or if -fPIC is also needed.
You
could use qcc instead of g++.

chris

\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I
get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
\

11

First, let’s confirm whether it is a pic problem - do an objdump -h on your
solib, if there is a rel.text section then you are linking
in some non-pic files somewhere, and I would check your link (maybe produce
a mapfile)

You can also narrow it down by looking at the text relocations (readelf -r),
since they will point to the non-pic functions.

Eg.

shared.c:
extern int func2(void);

int func(void)
{
return func2() * 2;
}

qcc -c -g shared.c

qcc -shared -o shared.so shared.o -g

readelf -r shared.so

Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries: Offset Info Type Symbol’s Value Symbol’s Name 000004b3 01e02 R_386_PC32 00000000 func2 Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries: Offset Info Type
Symbol’s Value Symbol’s Name 0000152c 00008 R_386_RELATIVE 00001528 00008 R_386_RELATIVE
Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2

Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type Symbol’s Value Symbol’s Name
0000152c 00008 R_386_RELATIVE
00001528 00008 R_386_RELATIVE

0x4b3 is the text relocation address, so we can objdump the shared object

objdump -D shared.so

[…]
000004ac :
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 08 sub $0x8,%esp
4b2: e8 fc ff ff ff call 4b3 <func+0x7>
4b7: 89 c0 mov %eax,%eax
4b9: 8d 14 00 lea (%eax,%eax,1),%edx
4bc: 89 d0 mov %edx,%eax
4be: eb 00 jmp 4c0 <func+0x14>
4c0: c9 leave
4c1: c3 ret
4c2: 90 nop
4c3: 90 nop
[…]

and we can see that the bad address is in the function func()

addr2line -e shared.so 0x4b3

shared.c:5

and the relocation refers to line 5 of shared.c

–
cburgess@qnx.com

12

Here is what I get:

objdump -h libqt-mt.so.3.0.2 | grep .rel.text

3 .rel.text 00000138 00122220 00122220 00122220 2**2

so there is some position dependent code! Then on to the readelf command:

readelf -r libqt-mt.so.3.0.2 | more

Relocation section ‘.rel.text’ at offset 0x122220 contains 39 entries:
Offset Info Type Symbol’s Value Symbol’s Name
006f842c 00008 R_386_RELATIVE
006f8434 3aab02 R_386_PC32 00000000 XextCreateExtension
006f8439 00008 R_386_RELATIVE
006f844e 00008 R_386_RELATIVE
006f8453 319a02 R_386_PC32 00000000 XextFindDisplay
006f8466 00008 R_386_RELATIVE
006f846c 00008 R_386_RELATIVE
006f8473 00008 R_386_RELATIVE
006f8478 149402 R_386_PC32 00000000 XextAddDisplay
006f8492 00008 R_386_RELATIVE
006f8497 46b302 R_386_PC32 00000000 XextRemoveDisplay
006f8504 00008 R_386_RELATIVE
006f850a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8528 3ec002 R_386_PC32 00000000 _XFlush
006f8563 338302 R_386_PC32 00000000 _XReply
006f85b8 130d02 R_386_PC32 00000000 malloc
006f85ec 00008 R_386_RELATIVE
006f85f2 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8610 3ec002 R_386_PC32 00000000 _XFlush
006f8649 338302 R_386_PC32 00000000 _XReply
006f86b8 00008 R_386_RELATIVE
006f86be 4b9f02 R_386_PC32 00000000 XMissingExtension
006f86dc 3ec002 R_386_PC32 00000000 _XFlush
006f8715 338302 R_386_PC32 00000000 _XReply
006f8784 00008 R_386_RELATIVE
006f878a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f87a8 3ec002 R_386_PC32 00000000 _XFlush
006f87e7 338302 R_386_PC32 00000000 _XReply
006f884b 19c902 R_386_PC32 006f84a0 XPanoramiXQueryExtension
006f8867 337602 R_386_PC32 006f84dc XPanoramiXQueryVersion
006f88a3 3ec002 R_386_PC32 00000000 _XFlush
006f88d6 338302 R_386_PC32 00000000 _XReply
006f893c 00008 R_386_RELATIVE
006f8945 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8963 3ec002 R_386_PC32 00000000 _XFlush
006f899c 338302 R_386_PC32 00000000 _XReply
006f89d9 130d02 R_386_PC32 00000000 malloc
006f89ff 45ec02 R_386_PC32 00000000 _XRead
006f8a4b 3e9802 R_386_PC32 00000000 _XEatData

Then following your example:

addr2line -e libqt-mt.so.3.0.2 0x122220

??:0

Does that mean one of my X libraries are not linked correctly?

Does anyone know of the top of their head which X library it is?

Thanks

–
Jens


“Colin Burgess” <cburgess@qnx.com> wrote in message
news:a7olga$qj0$1@nntp.qnx.com…

First, let’s confirm whether it is a pic problem - do an objdump -h on
your
solib, if there is a rel.text section then you are linking
in some non-pic files somewhere, and I would check your link (maybe
produce
a mapfile)

You can also narrow it down by looking at the text relocations
(readelf -r),
since they will point to the non-pic functions.

Eg.

shared.c:
extern int func2(void);

int func(void)
{
return func2() * 2;
}

qcc -c -g shared.c

qcc -shared -o shared.so shared.o -g

readelf -r shared.so

Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:

Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2
Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type

Symbol’s Value Symbol’s Name 0000152c 00008
R_386_RELATIVE 00001528

00008 R_386_RELATIVE

Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2

Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type Symbol’s Value Symbol’s Name
0000152c 00008 R_386_RELATIVE
00001528 00008 R_386_RELATIVE

0x4b3 is the text relocation address, so we can objdump the shared object

objdump -D shared.so

[…]
000004ac :
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 08 sub $0x8,%esp
4b2: e8 fc ff ff ff call 4b3 <func+0x7
4b7: 89 c0 mov %eax,%eax
4b9: 8d 14 00 lea (%eax,%eax,1),%edx
4bc: 89 d0 mov %edx,%eax
4be: eb 00 jmp 4c0 <func+0x14
4c0: c9 leave
4c1: c3 ret
4c2: 90 nop
4c3: 90 nop
[…]

and we can see that the bad address is in the function func()

addr2line -e shared.so 0x4b3

shared.c:5

and the relocation refers to line 5 of shared.c

–
cburgess@qnx.com

13

Could you be linking against the static X libs? What does
objdump -x libqt-mt.so.3.0.2 | grep NEEDED show

\

cburgess@qnx.com

14

It doesn’t seem like it:

objdump -x libqt-mt.so.3.0.2 | grep NEEDED

NEEDED libsocket.so.2
NEEDED libICE.so.6
NEEDED libSM.so.6
NEEDED libXext.so.6
NEEDED libX11.so.6
NEEDED libXrender.so.1
NEEDED libXft.so.1
NEEDED libfreetype.so.8
NEEDED libcpp.so.2
NEEDED libm.so.2
NEEDED libc.so.2

“Colin Burgess” <cburgess@qnx.com> wrote in message
news:a7qqco$gdr$1@nntp.qnx.com…

Could you be linking against the static X libs? What does
objdump -x libqt-mt.so.3.0.2 | grep NEEDED show

\

cburgess@qnx.com

15

The easiest way to find out where the problem is is to disassemble
your lib and look at the function that contains the address 0x6f8434
(the first R_386_PC32 relocation)

Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:

Here is what I get:

objdump -h libqt-mt.so.3.0.2 | grep .rel.text

3 .rel.text 00000138 00122220 00122220 00122220 2**2

so there is some position dependent code! Then on to the readelf command:

readelf -r libqt-mt.so.3.0.2 | more

Relocation section ‘.rel.text’ at offset 0x122220 contains 39 entries:
Offset Info Type Symbol’s Value Symbol’s Name
006f842c 00008 R_386_RELATIVE
006f8434 3aab02 R_386_PC32 00000000 XextCreateExtension
006f8439 00008 R_386_RELATIVE
006f844e 00008 R_386_RELATIVE
006f8453 319a02 R_386_PC32 00000000 XextFindDisplay
006f8466 00008 R_386_RELATIVE
006f846c 00008 R_386_RELATIVE
006f8473 00008 R_386_RELATIVE
006f8478 149402 R_386_PC32 00000000 XextAddDisplay
006f8492 00008 R_386_RELATIVE
006f8497 46b302 R_386_PC32 00000000 XextRemoveDisplay
006f8504 00008 R_386_RELATIVE
006f850a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8528 3ec002 R_386_PC32 00000000 _XFlush
006f8563 338302 R_386_PC32 00000000 _XReply
006f85b8 130d02 R_386_PC32 00000000 malloc
006f85ec 00008 R_386_RELATIVE
006f85f2 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8610 3ec002 R_386_PC32 00000000 _XFlush
006f8649 338302 R_386_PC32 00000000 _XReply
006f86b8 00008 R_386_RELATIVE
006f86be 4b9f02 R_386_PC32 00000000 XMissingExtension
006f86dc 3ec002 R_386_PC32 00000000 _XFlush
006f8715 338302 R_386_PC32 00000000 _XReply
006f8784 00008 R_386_RELATIVE
006f878a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f87a8 3ec002 R_386_PC32 00000000 _XFlush
006f87e7 338302 R_386_PC32 00000000 _XReply
006f884b 19c902 R_386_PC32 006f84a0 XPanoramiXQueryExtension
006f8867 337602 R_386_PC32 006f84dc XPanoramiXQueryVersion
006f88a3 3ec002 R_386_PC32 00000000 _XFlush
006f88d6 338302 R_386_PC32 00000000 _XReply
006f893c 00008 R_386_RELATIVE
006f8945 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8963 3ec002 R_386_PC32 00000000 _XFlush
006f899c 338302 R_386_PC32 00000000 _XReply
006f89d9 130d02 R_386_PC32 00000000 malloc
006f89ff 45ec02 R_386_PC32 00000000 _XRead
006f8a4b 3e9802 R_386_PC32 00000000 _XEatData

Then following your example:

addr2line -e libqt-mt.so.3.0.2 0x122220

??:0

Does that mean one of my X libraries are not linked correctly?

Does anyone know of the top of their head which X library it is?

Thanks

–
Jens



“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:a7olga$qj0$> 1@nntp.qnx.com> …
First, let’s confirm whether it is a pic problem - do an objdump -h on
your
solib, if there is a rel.text section then you are linking
in some non-pic files somewhere, and I would check your link (maybe
produce
a mapfile)

You can also narrow it down by looking at the text relocations
(readelf -r),
since they will point to the non-pic functions.

Eg.

shared.c:
extern int func2(void);

int func(void)
{
return func2() * 2;
}

qcc -c -g shared.c

qcc -shared -o shared.so shared.o -g

readelf -r shared.so

Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2
Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type
Symbol’s Value Symbol’s Name 0000152c 00008
R_386_RELATIVE 00001528
00008 R_386_RELATIVE
Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2

Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type Symbol’s Value Symbol’s Name
0000152c 00008 R_386_RELATIVE
00001528 00008 R_386_RELATIVE

0x4b3 is the text relocation address, so we can objdump the shared object

objdump -D shared.so

[…]
000004ac :
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 08 sub $0x8,%esp
4b2: e8 fc ff ff ff call 4b3 <func+0x7
4b7: 89 c0 mov %eax,%eax
4b9: 8d 14 00 lea (%eax,%eax,1),%edx
4bc: 89 d0 mov %edx,%eax
4be: eb 00 jmp 4c0 <func+0x14
4c0: c9 leave
4c1: c3 ret
4c2: 90 nop
4c3: 90 nop
[…]

and we can see that the bad address is in the function func()

addr2line -e shared.so 0x4b3

shared.c:5

and the relocation refers to line 5 of shared.c

–
cburgess@qnx.com

–
cburgess@qnx.com

16

Here is what the disassembly gave:

006f8430 <find_display+0x10>:
6f8430: 00 75 15 add %dh,0x15(%ebp)
6f8433: e8 fc ff ff ff call 6f8434 <find_display+0x14>
6f8438: a3 60 b8 88 00 mov %eax,0x88b860
6f843d: 85 c0 test %eax,%eax
6f843f: 75 07 jne 6f8448 <find_display+0x28>

Now is find_display() in the offending library or is it calling the
offending library?

Jens

“Colin Burgess” <cburgess@qnx.com> wrote in message
news:a7r0em$kjk$1@nntp.qnx.com…

The easiest way to find out where the problem is is to disassemble
your lib and look at the function that contains the address 0x6f8434
(the first R_386_PC32 relocation)

Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
Here is what I get:

objdump -h libqt-mt.so.3.0.2 | grep .rel.text

3 .rel.text 00000138 00122220 00122220 00122220 2**2

so there is some position dependent code! Then on to the readelf
command:

readelf -r libqt-mt.so.3.0.2 | more

Relocation section ‘.rel.text’ at offset 0x122220 contains 39 entries:
Offset Info Type Symbol’s Value Symbol’s Name
006f842c 00008 R_386_RELATIVE
006f8434 3aab02 R_386_PC32 00000000 XextCreateExtension
006f8439 00008 R_386_RELATIVE
006f844e 00008 R_386_RELATIVE
006f8453 319a02 R_386_PC32 00000000 XextFindDisplay
006f8466 00008 R_386_RELATIVE
006f846c 00008 R_386_RELATIVE
006f8473 00008 R_386_RELATIVE
006f8478 149402 R_386_PC32 00000000 XextAddDisplay
006f8492 00008 R_386_RELATIVE
006f8497 46b302 R_386_PC32 00000000 XextRemoveDisplay
006f8504 00008 R_386_RELATIVE
006f850a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8528 3ec002 R_386_PC32 00000000 _XFlush
006f8563 338302 R_386_PC32 00000000 _XReply
006f85b8 130d02 R_386_PC32 00000000 malloc
006f85ec 00008 R_386_RELATIVE
006f85f2 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8610 3ec002 R_386_PC32 00000000 _XFlush
006f8649 338302 R_386_PC32 00000000 _XReply
006f86b8 00008 R_386_RELATIVE
006f86be 4b9f02 R_386_PC32 00000000 XMissingExtension
006f86dc 3ec002 R_386_PC32 00000000 _XFlush
006f8715 338302 R_386_PC32 00000000 _XReply
006f8784 00008 R_386_RELATIVE
006f878a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f87a8 3ec002 R_386_PC32 00000000 _XFlush
006f87e7 338302 R_386_PC32 00000000 _XReply
006f884b 19c902 R_386_PC32 006f84a0
XPanoramiXQueryExtension
006f8867 337602 R_386_PC32 006f84dc
XPanoramiXQueryVersion
006f88a3 3ec002 R_386_PC32 00000000 _XFlush
006f88d6 338302 R_386_PC32 00000000 _XReply
006f893c 00008 R_386_RELATIVE
006f8945 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8963 3ec002 R_386_PC32 00000000 _XFlush
006f899c 338302 R_386_PC32 00000000 _XReply
006f89d9 130d02 R_386_PC32 00000000 malloc
006f89ff 45ec02 R_386_PC32 00000000 _XRead
006f8a4b 3e9802 R_386_PC32 00000000 _XEatData

Then following your example:

addr2line -e libqt-mt.so.3.0.2 0x122220

??:0

Does that mean one of my X libraries are not linked correctly?

Does anyone know of the top of their head which X library it is?

Thanks

–
Jens


“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:a7olga$qj0$> 1@nntp.qnx.com> …
First, let’s confirm whether it is a pic problem - do an objdump -h on
your
solib, if there is a rel.text section then you are linking
in some non-pic files somewhere, and I would check your link (maybe
produce
a mapfile)

You can also narrow it down by looking at the text relocations
(readelf -r),
since they will point to the non-pic functions.

Eg.

shared.c:
extern int func2(void);

int func(void)
{
return func2() * 2;
}

qcc -c -g shared.c

qcc -shared -o shared.so shared.o -g

readelf -r shared.so

Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2
Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type
Symbol’s Value Symbol’s Name 0000152c 00008
R_386_RELATIVE 00001528
00008 R_386_RELATIVE
Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2

Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type Symbol’s Value Symbol’s Name
0000152c 00008 R_386_RELATIVE
00001528 00008 R_386_RELATIVE

0x4b3 is the text relocation address, so we can objdump the shared
object

objdump -D shared.so

[…]
000004ac :
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 08 sub $0x8,%esp
4b2: e8 fc ff ff ff call 4b3 <func+0x7
4b7: 89 c0 mov %eax,%eax
4b9: 8d 14 00 lea (%eax,%eax,1),%edx
4bc: 89 d0 mov %edx,%eax
4be: eb 00 jmp 4c0 <func+0x14
4c0: c9 leave
4c1: c3 ret
4c2: 90 nop
4c3: 90 nop
[…]

and we can see that the bad address is in the function func()

addr2line -e shared.so 0x4b3

shared.c:5

and the relocation refers to line 5 of shared.c

–
cburgess@qnx.com



\

cburgess@qnx.com

17

Here is a slightly better disassembly:

006f8420 <find_display>:
6f8420: 55 push %ebp
6f8421: 89 e5 mov %esp,%ebp
6f8423: 83 ec 14 sub $0x14,%esp
6f8426: 53 push %ebx
6f8427: 8b 5d 08 mov 0x8(%ebp),%ebx
6f842a: 83 3d 60 b8 88 00 00 cmpl $0x0,0x88b860
6f8431: 75 15 jne 6f8448 <find_display+0x28>
6f8433: e8 fc ff ff ff call 6f8434 <find_display+0x14>
6f8438: a3 60 b8 88 00 mov %eax,0x88b860
6f843d: 85 c0 test %eax,%eax
6f843f: 75 07 jne 6f8448 <find_display+0x28>
6f8441: 31 c0 xor %eax,%eax
6f8443: eb 37 jmp 6f847c <find_display+0x5c>
6f8445: 8d 76 00 lea 0x0(%esi),%esi
6f8448: 83 c4 f8 add $0xfffffff8,%esp
6f844b: 53 push %ebx
6f844c: ff 35 60 b8 88 00 pushl 0x88b860
6f8452: e8 fc ff ff ff call 6f8453 <find_display+0x33>
6f8457: 83 c4 10 add $0x10,%esp
6f845a: 85 c0 test %eax,%eax
6f845c: 75 1e jne 6f847c <find_display+0x5c>
6f845e: 83 c4 f8 add $0xfffffff8,%esp
6f8461: 6a 00 push $0x0
6f8463: 6a 00 push $0x0
6f8465: 68 80 b8 88 00 push $0x88b880
6f846a: ff 35 64 b8 88 00 pushl 0x88b864
6f8470: 53 push %ebx
6f8471: ff 35 60 b8 88 00 pushl 0x88b860
6f8477: e8 fc ff ff ff call 6f8478 <find_display+0x58>
6f847c: 8b 5d e8 mov 0xffffffe8(%ebp),%ebx
6f847f: c9 leave
6f8480: c3 ret
6f8481: 8d 76 00 lea 0x0(%esi),%esi

“Jens H Jorgensen” <jhj@remove-nospam-videk.com> wrote in message
news:a7sk2n$7sp$1@inn.qnx.com…

Here is what the disassembly gave:

006f8430 <find_display+0x10>:
6f8430: 00 75 15 add %dh,0x15(%ebp)
6f8433: e8 fc ff ff ff call 6f8434 <find_display+0x14
6f8438: a3 60 b8 88 00 mov %eax,0x88b860
6f843d: 85 c0 test %eax,%eax
6f843f: 75 07 jne 6f8448 <find_display+0x28

Now is find_display() in the offending library or is it calling the
offending library?

Jens

“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:a7r0em$kjk$> 1@nntp.qnx.com> …
The easiest way to find out where the problem is is to disassemble
your lib and look at the function that contains the address 0x6f8434
(the first R_386_PC32 relocation)

Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
Here is what I get:

objdump -h libqt-mt.so.3.0.2 | grep .rel.text

3 .rel.text 00000138 00122220 00122220 00122220 2**2

so there is some position dependent code! Then on to the readelf
command:

readelf -r libqt-mt.so.3.0.2 | more

Relocation section ‘.rel.text’ at offset 0x122220 contains 39 entries:
Offset Info Type Symbol’s Value Symbol’s Name
006f842c 00008 R_386_RELATIVE
006f8434 3aab02 R_386_PC32 00000000 XextCreateExtension
006f8439 00008 R_386_RELATIVE
006f844e 00008 R_386_RELATIVE
006f8453 319a02 R_386_PC32 00000000 XextFindDisplay
006f8466 00008 R_386_RELATIVE
006f846c 00008 R_386_RELATIVE
006f8473 00008 R_386_RELATIVE
006f8478 149402 R_386_PC32 00000000 XextAddDisplay
006f8492 00008 R_386_RELATIVE
006f8497 46b302 R_386_PC32 00000000 XextRemoveDisplay
006f8504 00008 R_386_RELATIVE
006f850a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8528 3ec002 R_386_PC32 00000000 _XFlush
006f8563 338302 R_386_PC32 00000000 _XReply
006f85b8 130d02 R_386_PC32 00000000 malloc
006f85ec 00008 R_386_RELATIVE
006f85f2 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8610 3ec002 R_386_PC32 00000000 _XFlush
006f8649 338302 R_386_PC32 00000000 _XReply
006f86b8 00008 R_386_RELATIVE
006f86be 4b9f02 R_386_PC32 00000000 XMissingExtension
006f86dc 3ec002 R_386_PC32 00000000 _XFlush
006f8715 338302 R_386_PC32 00000000 _XReply
006f8784 00008 R_386_RELATIVE
006f878a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f87a8 3ec002 R_386_PC32 00000000 _XFlush
006f87e7 338302 R_386_PC32 00000000 _XReply
006f884b 19c902 R_386_PC32 006f84a0
XPanoramiXQueryExtension
006f8867 337602 R_386_PC32 006f84dc
XPanoramiXQueryVersion
006f88a3 3ec002 R_386_PC32 00000000 _XFlush
006f88d6 338302 R_386_PC32 00000000 _XReply
006f893c 00008 R_386_RELATIVE
006f8945 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8963 3ec002 R_386_PC32 00000000 _XFlush
006f899c 338302 R_386_PC32 00000000 _XReply
006f89d9 130d02 R_386_PC32 00000000 malloc
006f89ff 45ec02 R_386_PC32 00000000 _XRead
006f8a4b 3e9802 R_386_PC32 00000000 _XEatData

Then following your example:

addr2line -e libqt-mt.so.3.0.2 0x122220

??:0

Does that mean one of my X libraries are not linked correctly?

Does anyone know of the top of their head which X library it is?

Thanks

–
Jens


“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:a7olga$qj0$> 1@nntp.qnx.com> …
First, let’s confirm whether it is a pic problem - do an objdump -h
on
your
solib, if there is a rel.text section then you are linking
in some non-pic files somewhere, and I would check your link (maybe
produce
a mapfile)

You can also narrow it down by looking at the text relocations
(readelf -r),
since they will point to the non-pic functions.

Eg.

shared.c:
extern int func2(void);

int func(void)
{
return func2() * 2;
}

qcc -c -g shared.c

qcc -shared -o shared.so shared.o -g

readelf -r shared.so

Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2
Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type
Symbol’s Value Symbol’s Name 0000152c 00008
R_386_RELATIVE
00001528
00008 R_386_RELATIVE
Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2

Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type Symbol’s Value Symbol’s Name
0000152c 00008 R_386_RELATIVE
00001528 00008 R_386_RELATIVE

0x4b3 is the text relocation address, so we can objdump the shared
object

objdump -D shared.so

[…]
000004ac :
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 08 sub $0x8,%esp
4b2: e8 fc ff ff ff call 4b3 <func+0x7
4b7: 89 c0 mov %eax,%eax
4b9: 8d 14 00 lea (%eax,%eax,1),%edx
4bc: 89 d0 mov %edx,%eax
4be: eb 00 jmp 4c0 <func+0x14
4c0: c9 leave
4c1: c3 ret
4c2: 90 nop
4c3: 90 nop
[…]

and we can see that the bad address is in the function func()

addr2line -e shared.so 0x4b3

shared.c:5

and the relocation refers to line 5 of shared.c

–
cburgess@qnx.com



\

cburgess@qnx.com

18

find_display is in the offending library.

Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:

Here is what the disassembly gave:

006f8430 <find_display+0x10>:
6f8430: 00 75 15 add %dh,0x15(%ebp)
6f8433: e8 fc ff ff ff call 6f8434 <find_display+0x14
6f8438: a3 60 b8 88 00 mov %eax,0x88b860
6f843d: 85 c0 test %eax,%eax
6f843f: 75 07 jne 6f8448 <find_display+0x28

Now is find_display() in the offending library or is it calling the
offending library?

Jens

“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:a7r0em$kjk$> 1@nntp.qnx.com> …
The easiest way to find out where the problem is is to disassemble
your lib and look at the function that contains the address 0x6f8434
(the first R_386_PC32 relocation)

Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
Here is what I get:

objdump -h libqt-mt.so.3.0.2 | grep .rel.text

3 .rel.text 00000138 00122220 00122220 00122220 2**2

so there is some position dependent code! Then on to the readelf
command:

readelf -r libqt-mt.so.3.0.2 | more

Relocation section ‘.rel.text’ at offset 0x122220 contains 39 entries:
Offset Info Type Symbol’s Value Symbol’s Name
006f842c 00008 R_386_RELATIVE
006f8434 3aab02 R_386_PC32 00000000 XextCreateExtension
006f8439 00008 R_386_RELATIVE
006f844e 00008 R_386_RELATIVE
006f8453 319a02 R_386_PC32 00000000 XextFindDisplay
006f8466 00008 R_386_RELATIVE
006f846c 00008 R_386_RELATIVE
006f8473 00008 R_386_RELATIVE
006f8478 149402 R_386_PC32 00000000 XextAddDisplay
006f8492 00008 R_386_RELATIVE
006f8497 46b302 R_386_PC32 00000000 XextRemoveDisplay
006f8504 00008 R_386_RELATIVE
006f850a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8528 3ec002 R_386_PC32 00000000 _XFlush
006f8563 338302 R_386_PC32 00000000 _XReply
006f85b8 130d02 R_386_PC32 00000000 malloc
006f85ec 00008 R_386_RELATIVE
006f85f2 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8610 3ec002 R_386_PC32 00000000 _XFlush
006f8649 338302 R_386_PC32 00000000 _XReply
006f86b8 00008 R_386_RELATIVE
006f86be 4b9f02 R_386_PC32 00000000 XMissingExtension
006f86dc 3ec002 R_386_PC32 00000000 _XFlush
006f8715 338302 R_386_PC32 00000000 _XReply
006f8784 00008 R_386_RELATIVE
006f878a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f87a8 3ec002 R_386_PC32 00000000 _XFlush
006f87e7 338302 R_386_PC32 00000000 _XReply
006f884b 19c902 R_386_PC32 006f84a0
XPanoramiXQueryExtension
006f8867 337602 R_386_PC32 006f84dc
XPanoramiXQueryVersion
006f88a3 3ec002 R_386_PC32 00000000 _XFlush
006f88d6 338302 R_386_PC32 00000000 _XReply
006f893c 00008 R_386_RELATIVE
006f8945 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8963 3ec002 R_386_PC32 00000000 _XFlush
006f899c 338302 R_386_PC32 00000000 _XReply
006f89d9 130d02 R_386_PC32 00000000 malloc
006f89ff 45ec02 R_386_PC32 00000000 _XRead
006f8a4b 3e9802 R_386_PC32 00000000 _XEatData

Then following your example:

addr2line -e libqt-mt.so.3.0.2 0x122220

??:0

Does that mean one of my X libraries are not linked correctly?

Does anyone know of the top of their head which X library it is?

Thanks

–
Jens


“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:a7olga$qj0$> 1@nntp.qnx.com> …
First, let’s confirm whether it is a pic problem - do an objdump -h on
your
solib, if there is a rel.text section then you are linking
in some non-pic files somewhere, and I would check your link (maybe
produce
a mapfile)

You can also narrow it down by looking at the text relocations
(readelf -r),
since they will point to the non-pic functions.

Eg.

shared.c:
extern int func2(void);

int func(void)
{
return func2() * 2;
}

qcc -c -g shared.c

qcc -shared -o shared.so shared.o -g

readelf -r shared.so

Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2
Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type
Symbol’s Value Symbol’s Name 0000152c 00008
R_386_RELATIVE 00001528
00008 R_386_RELATIVE
Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2

Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type Symbol’s Value Symbol’s Name
0000152c 00008 R_386_RELATIVE
00001528 00008 R_386_RELATIVE

0x4b3 is the text relocation address, so we can objdump the shared
object

objdump -D shared.so

[…]
000004ac :
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 08 sub $0x8,%esp
4b2: e8 fc ff ff ff call 4b3 <func+0x7
4b7: 89 c0 mov %eax,%eax
4b9: 8d 14 00 lea (%eax,%eax,1),%edx
4bc: 89 d0 mov %edx,%eax
4be: eb 00 jmp 4c0 <func+0x14
4c0: c9 leave
4c1: c3 ret
4c2: 90 nop
4c3: 90 nop
[…]

and we can see that the bad address is in the function func()

addr2line -e shared.so 0x4b3

shared.c:5

and the relocation refers to line 5 of shared.c

–
cburgess@qnx.com



\

cburgess@qnx.com

–
cburgess@qnx.com

19

BTW - this is definately not PIC code.

I found that there is a find_display() in libXext.so, but the one I have
is PIC, and the lib is shared, and in any case, you are linking against
libXext.so

Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:

Here is a slightly better disassembly:

006f8420 <find_display>:
6f8420: 55 push %ebp
6f8421: 89 e5 mov %esp,%ebp
6f8423: 83 ec 14 sub $0x14,%esp
6f8426: 53 push %ebx
6f8427: 8b 5d 08 mov 0x8(%ebp),%ebx
6f842a: 83 3d 60 b8 88 00 00 cmpl $0x0,0x88b860
6f8431: 75 15 jne 6f8448 <find_display+0x28
6f8433: e8 fc ff ff ff call 6f8434 <find_display+0x14
6f8438: a3 60 b8 88 00 mov %eax,0x88b860
6f843d: 85 c0 test %eax,%eax
6f843f: 75 07 jne 6f8448 <find_display+0x28
6f8441: 31 c0 xor %eax,%eax
6f8443: eb 37 jmp 6f847c <find_display+0x5c
6f8445: 8d 76 00 lea 0x0(%esi),%esi
6f8448: 83 c4 f8 add $0xfffffff8,%esp
6f844b: 53 push %ebx
6f844c: ff 35 60 b8 88 00 pushl 0x88b860
6f8452: e8 fc ff ff ff call 6f8453 <find_display+0x33
6f8457: 83 c4 10 add $0x10,%esp
6f845a: 85 c0 test %eax,%eax
6f845c: 75 1e jne 6f847c <find_display+0x5c
6f845e: 83 c4 f8 add $0xfffffff8,%esp
6f8461: 6a 00 push $0x0
6f8463: 6a 00 push $0x0
6f8465: 68 80 b8 88 00 push $0x88b880
6f846a: ff 35 64 b8 88 00 pushl 0x88b864
6f8470: 53 push %ebx
6f8471: ff 35 60 b8 88 00 pushl 0x88b860
6f8477: e8 fc ff ff ff call 6f8478 <find_display+0x58
6f847c: 8b 5d e8 mov 0xffffffe8(%ebp),%ebx
6f847f: c9 leave
6f8480: c3 ret
6f8481: 8d 76 00 lea 0x0(%esi),%esi

“Jens H Jorgensen” <> jhj@remove-nospam-videk.com> > wrote in message
news:a7sk2n$7sp$> 1@inn.qnx.com> …
Here is what the disassembly gave:

006f8430 <find_display+0x10>:
6f8430: 00 75 15 add %dh,0x15(%ebp)
6f8433: e8 fc ff ff ff call 6f8434 <find_display+0x14
6f8438: a3 60 b8 88 00 mov %eax,0x88b860
6f843d: 85 c0 test %eax,%eax
6f843f: 75 07 jne 6f8448 <find_display+0x28

Now is find_display() in the offending library or is it calling the
offending library?

Jens

“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:a7r0em$kjk$> 1@nntp.qnx.com> …
The easiest way to find out where the problem is is to disassemble
your lib and look at the function that contains the address 0x6f8434
(the first R_386_PC32 relocation)

Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
Here is what I get:

objdump -h libqt-mt.so.3.0.2 | grep .rel.text

3 .rel.text 00000138 00122220 00122220 00122220 2**2

so there is some position dependent code! Then on to the readelf
command:

readelf -r libqt-mt.so.3.0.2 | more

Relocation section ‘.rel.text’ at offset 0x122220 contains 39 entries:
Offset Info Type Symbol’s Value Symbol’s Name
006f842c 00008 R_386_RELATIVE
006f8434 3aab02 R_386_PC32 00000000 XextCreateExtension
006f8439 00008 R_386_RELATIVE
006f844e 00008 R_386_RELATIVE
006f8453 319a02 R_386_PC32 00000000 XextFindDisplay
006f8466 00008 R_386_RELATIVE
006f846c 00008 R_386_RELATIVE
006f8473 00008 R_386_RELATIVE
006f8478 149402 R_386_PC32 00000000 XextAddDisplay
006f8492 00008 R_386_RELATIVE
006f8497 46b302 R_386_PC32 00000000 XextRemoveDisplay
006f8504 00008 R_386_RELATIVE
006f850a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8528 3ec002 R_386_PC32 00000000 _XFlush
006f8563 338302 R_386_PC32 00000000 _XReply
006f85b8 130d02 R_386_PC32 00000000 malloc
006f85ec 00008 R_386_RELATIVE
006f85f2 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8610 3ec002 R_386_PC32 00000000 _XFlush
006f8649 338302 R_386_PC32 00000000 _XReply
006f86b8 00008 R_386_RELATIVE
006f86be 4b9f02 R_386_PC32 00000000 XMissingExtension
006f86dc 3ec002 R_386_PC32 00000000 _XFlush
006f8715 338302 R_386_PC32 00000000 _XReply
006f8784 00008 R_386_RELATIVE
006f878a 4b9f02 R_386_PC32 00000000 XMissingExtension
006f87a8 3ec002 R_386_PC32 00000000 _XFlush
006f87e7 338302 R_386_PC32 00000000 _XReply
006f884b 19c902 R_386_PC32 006f84a0
XPanoramiXQueryExtension
006f8867 337602 R_386_PC32 006f84dc
XPanoramiXQueryVersion
006f88a3 3ec002 R_386_PC32 00000000 _XFlush
006f88d6 338302 R_386_PC32 00000000 _XReply
006f893c 00008 R_386_RELATIVE
006f8945 4b9f02 R_386_PC32 00000000 XMissingExtension
006f8963 3ec002 R_386_PC32 00000000 _XFlush
006f899c 338302 R_386_PC32 00000000 _XReply
006f89d9 130d02 R_386_PC32 00000000 malloc
006f89ff 45ec02 R_386_PC32 00000000 _XRead
006f8a4b 3e9802 R_386_PC32 00000000 _XEatData

Then following your example:

addr2line -e libqt-mt.so.3.0.2 0x122220

??:0

Does that mean one of my X libraries are not linked correctly?

Does anyone know of the top of their head which X library it is?

Thanks

–
Jens


“Colin Burgess” <> cburgess@qnx.com> > wrote in message
news:a7olga$qj0$> 1@nntp.qnx.com> …
First, let’s confirm whether it is a pic problem - do an objdump -h
on
your
solib, if there is a rel.text section then you are linking
in some non-pic files somewhere, and I would check your link (maybe
produce
a mapfile)

You can also narrow it down by looking at the text relocations
(readelf -r),
since they will point to the non-pic functions.

Eg.

shared.c:
extern int func2(void);

int func(void)
{
return func2() * 2;
}

qcc -c -g shared.c

qcc -shared -o shared.so shared.o -g

readelf -r shared.so

Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2
Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type
Symbol’s Value Symbol’s Name 0000152c 00008
R_386_RELATIVE
00001528
00008 R_386_RELATIVE
Relocation section ‘.rel.text’ at offset 0x438 contains 1 entries:
Offset Info Type Symbol’s Value Symbol’s Name
000004b3 01e02 R_386_PC32 00000000 func2

Relocation section ‘.rel.data’ at offset 0x440 contains 2 entries:
Offset Info Type Symbol’s Value Symbol’s Name
0000152c 00008 R_386_RELATIVE
00001528 00008 R_386_RELATIVE

0x4b3 is the text relocation address, so we can objdump the shared
object

objdump -D shared.so

[…]
000004ac :
4ac: 55 push %ebp
4ad: 89 e5 mov %esp,%ebp
4af: 83 ec 08 sub $0x8,%esp
4b2: e8 fc ff ff ff call 4b3 <func+0x7
4b7: 89 c0 mov %eax,%eax
4b9: 8d 14 00 lea (%eax,%eax,1),%edx
4bc: 89 d0 mov %edx,%eax
4be: eb 00 jmp 4c0 <func+0x14
4c0: c9 leave
4c1: c3 ret
4c2: 90 nop
4c3: 90 nop
[…]

and we can see that the bad address is in the function func()

addr2line -e shared.so 0x4b3

shared.c:5

and the relocation refers to line 5 of shared.c

–
cburgess@qnx.com



\

cburgess@qnx.com

–
cburgess@qnx.com

20

Also - this is the non-PIC code for find_display that is in libXext.a,
so you must be linking against that before you are linking against libXext.so

Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:

Here is a slightly better disassembly:

006f8420 <find_display>:
6f8420: 55 push %ebp
6f8421: 89 e5 mov %esp,%ebp
6f8423: 83 ec 14 sub $0x14,%esp
6f8426: 53 push %ebx
6f8427: 8b 5d 08 mov 0x8(%ebp),%ebx
6f842a: 83 3d 60 b8 88 00 00 cmpl $0x0,0x88b860
6f8431: 75 15 jne 6f8448 <find_display+0x28
6f8433: e8 fc ff ff ff call 6f8434 <find_display+0x14
6f8438: a3 60 b8 88 00 mov %eax,0x88b860
6f843d: 85 c0 test %eax,%eax
6f843f: 75 07 jne 6f8448 <find_display+0x28
6f8441: 31 c0 xor %eax,%eax
6f8443: eb 37 jmp 6f847c <find_display+0x5c
6f8445: 8d 76 00 lea 0x0(%esi),%esi
6f8448: 83 c4 f8 add $0xfffffff8,%esp
6f844b: 53 push %ebx
6f844c: ff 35 60 b8 88 00 pushl 0x88b860
6f8452: e8 fc ff ff ff call 6f8453 <find_display+0x33
6f8457: 83 c4 10 add $0x10,%esp
6f845a: 85 c0 test %eax,%eax
6f845c: 75 1e jne 6f847c <find_display+0x5c
6f845e: 83 c4 f8 add $0xfffffff8,%esp
6f8461: 6a 00 push $0x0
6f8463: 6a 00 push $0x0
6f8465: 68 80 b8 88 00 push $0x88b880
6f846a: ff 35 64 b8 88 00 pushl 0x88b864
6f8470: 53 push %ebx
6f8471: ff 35 60 b8 88 00 pushl 0x88b860
6f8477: e8 fc ff ff ff call 6f8478 <find_display+0x58
6f847c: 8b 5d e8 mov 0xffffffe8(%ebp),%ebx
6f847f: c9 leave
6f8480: c3 ret
6f8481: 8d 76 00 lea 0x0(%esi),%esi

–
cburgess@qnx.com