[Bug ld/1150] undefined reference to `_mpi_sgi_init'

[michael at weiser dot dinsnail dot net]

------- Additional Comments From michael at weiser dot dinsnail dot net  
2005-11-09 21:16 -------
Created an attachment (id=753)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=753&action=view)
testcase for optional symbols

Okay, I gave it a try to build a testcase. It's included in the attachment.
It's using the irix as to produce some object files using optional symbols.
Then it links them using irix ld as well as binutils ld to demonstrate where
binutils ld fails. This should be reproducable with a cross-ld for elf64bmip.

The files are:

os.s: defines a dword named os with value 73 which is read from ot.s

ot.s: has a function ot which reads the value of os if it is linked in,
otherwise returns -1. The linkage detection is done using the special
libc-symbol __missing_function_. If the linker can't find the definition of an
optional symbol it maps it to __missing_function_ which is defined in libc.so.
This one is optional and weak itself. The program can detect at runtime if a
specific symbol is compiled in by comparing its address to that of
__missing_function_. If they're equal the symbol has been mapped and not
compiled in. If they're different, the symbol is actually present.

start.s: defines __start, _environ and __missing_function_ to allow link tests
without actually having the irix crt1.o, crtn.o and libc.so around. The
resulting binaries will segfault but binutils ld will fail linking before that.


otw.s: is dynamically generated from ot.s by adding a .weakext os definition.
By accident I discovered that binutils ld will link the objects if os is
defined weak external. But the resulting executable will segfault or give bogus
results, so it isn't actually worth much.

The above files are compiled into objects and linked into binaries. Executables
ending in -bu are linked using binutils ld, the others by using irix ld. The
meaning is as follows:

ot-opt: linking ot.o and os.o into a binary so that the optional symbol can be
resolved, works with both ld's
ot-noopt: linking ot.o without os.o so that the optional symbol can't be
resolved and has to be mapped to __missing_function_
otw-*: same as above but using the weak-external-defined os, works with both
ld's but gives bogues executable with binutils ld.

Output on irix looks like this when doing make all to link the programs using
irix ld:

address@hidden ot]$ make all
        as -64 -o start.o start.s
        as -64 -o ot.o ot.s
        as -64 -o os.o os.s
        ld -64 -o ot-opt /usr/lib64/mips4/crt1.o ot.o os.o
/usr/lib64/mips4/crtn.o -lc
        ld -64 -o ot-noopt /usr/lib64/mips4/crt1.o ot.o /usr/lib64/mips4/crtn.o
-lc
        sed -e "s,/\* \(.weak.*\) \*/,\1," ot.s >otw.s
        as -64 -o otw.o otw.s
        ld -64 -o otw-opt /usr/lib64/mips4/crt1.o otw.o os.o
/usr/lib64/mips4/crtn.o -lc
        ld -64 -o otw-noopt /usr/lib64/mips4/crt1.o otw.o
/usr/lib64/mips4/crtn.o -lc
        ./ot-opt
*** Error code 73 (bu21) (ignored)
        ./ot-noopt
*** Error code 255 (bu21) (ignored)
        ./otw-opt
*** Error code 73 (bu21) (ignored)
        ./otw-noopt
*** Error code 255 (bu21) (ignored)

The error codes carry the information: ot-opt and otw-opt have os compiled in
and return its value 73. ot-noopt and otw-noopt don't have os compiled in and
give -1.

With binutils ld it looks as follows:

address@hidden ot]$ make bu
        as -64 -o start.o start.s
        as -64 -o ot.o ot.s
        as -64 -o os.o os.s
        /usr/local/bin/ld -melf64bmip -o ot-opt-bu /usr/lib64/mips4/crt1.o ot.o
os.o /usr/lib64/mips4/crtn.o -lc
        /usr/local/bin/ld -melf64bmip -o ot-noopt-bu /usr/lib64/mips4/crt1.o
ot.o /usr/lib64/mips4/crtn.o -lc
ot.o: In function `main':
/home/michael/ot/ot.s:27: undefined reference to `os'
/home/michael/ot/ot.s:38: undefined reference to `os'
*** Error code 1 (bu21) (ignored)
        sed -e "s,/\* \(.weak.*\) \*/,\1," ot.s >otw.s
        as -64 -o otw.o otw.s
        /usr/local/bin/ld -melf64bmip -o otw-opt-bu /usr/lib64/mips4/crt1.o
otw.o os.o /usr/lib64/mips4/crtn.o -lc
        /usr/local/bin/ld -melf64bmip -o otw-noopt-bu /usr/lib64/mips4/crt1.o
otw.o /usr/lib64/mips4/crtn.o -lc
        [ -x ot-opt-bu ] && ./ot-opt-bu
*** Error code 73 (bu21) (ignored)
        [ -x ot-noopt-bu ] && ./ot-noopt-bu
*** Error code 1 (bu21) (ignored)
        [ -x otw-opt-bu ] && ./otw-opt-bu
*** Error code 73 (bu21) (ignored)
        [ -x otw-noopt-bu ] && ./otw-noopt-bu
*** Termination code 139 (bu21) (ignored)

ot-opt-bu and otw-opt-bu work, but ot-noopt-bu doesn't link and otw-noopt-bu
segfaults.

I can reproduce the link problem with a elf64bmip binutils ld on may Mac OS X
10.3 iBook:

address@hidden:~/nobak/src/ot #
PATH=/Users/michael/bin/cross-mips-sgi-irix6.5/mips-sgi-irix6.5/bin/:$PATH make
ot-noopt-bu
ld -melf64bmip -o ot-noopt-bu start.o ot.o  
ot.o: In function `main':
/home/michael/ot/ot.s:27: undefined reference to `os'
/home/michael/ot/ot.s:38: undefined reference to `os'
make: [ot-noopt-bu] Error 1 (ignored)

All necessary object files are included. There may still be some braindamage in
the whole testcase due to misunderstandings on my part. I certainly don't hope
so but I'm not that much of an mips assembler or irix linker crack. :)

BTW: I produced the assembler code by writing short snippets of C code,
compiling them into assembler using gcc-4.0.2 and adding the optional symbol
stuff then. So the asm should be reasonable okay.

Hope it helps.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=1150

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.