Re: failure of dlpreopen on ia64/linux/gcc

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Fri, Sep 03, 2004 at 03:36:45PM CEST:
> The Libtool test suite (current CVS HEAD as well as 1.5) fails on
> ia64/linux/gcc in several tests.  I think the reason is that on
> ia64/linux, the linker (similar to ia64/hpux) also distinguishes data
> from code symbols, which make dlpreopen fail on functions. 

Ok, seems that first stab at a patch did not make the crowd cheer.
Let's be a bit more elaborate, example given is from libtool/tests/demo:

Looking at the generated file helldlS.c, which lists the external symbol
declarations for the compiler (use RM=echo to prevent the libtool script
from removing this file):

/* External symbol declarations for the compiler. */
extern int foo;
extern int hello;
extern int nothing;
/* ... */

If I keep this intermediate file and change these manually to:

/* External symbol declarations for the compiler. */
extern int foo();
extern int hello();
extern int nothing;

then demo-exec.test succeeds.  objdump -r shows the difference:

$ objdump -r helldlS-bad.o

helldlS-bad.o:     file format elf64-ia64-little

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE 
0000000000000002 LTOFF22           lt__PROGRAM__LTX_preloaded_symbols


RELOCATION RECORDS FOR [.data]:
OFFSET           TYPE              VALUE 
0000000000000000 DIR64LSB          .rodata+0x0000000000000028
0000000000000010 DIR64LSB          .rodata+0x0000000000000018
0000000000000020 DIR64LSB          .rodata+0x0000000000000010
0000000000000028 DIR64LSB          hello
0000000000000030 DIR64LSB          .rodata+0x0000000000000008
0000000000000038 DIR64LSB          foo
0000000000000040 DIR64LSB          .rodata
0000000000000048 DIR64LSB          nothing


RELOCATION RECORDS FOR [.IA_64.unwind]:
OFFSET           TYPE              VALUE 
0000000000000000 SEGREL64LSB       .text
0000000000000008 SEGREL64LSB       .text+0x0000000000000020
0000000000000010 SEGREL64LSB       .IA_64.unwind_info


$ objdump -r helldlS-good.o

helldlS-good.o:     file format elf64-ia64-little

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE 
0000000000000002 LTOFF22           lt__PROGRAM__LTX_preloaded_symbols


RELOCATION RECORDS FOR [.data]:
OFFSET           TYPE              VALUE 
0000000000000000 DIR64LSB          .rodata+0x0000000000000028
0000000000000010 DIR64LSB          .rodata+0x0000000000000018
0000000000000020 DIR64LSB          .rodata+0x0000000000000010
0000000000000028 FPTR64LSB         hello
0000000000000030 DIR64LSB          .rodata+0x0000000000000008
0000000000000038 FPTR64LSB         foo
0000000000000040 DIR64LSB          .rodata
0000000000000048 DIR64LSB          nothing


RELOCATION RECORDS FOR [.IA_64.unwind]:
OFFSET           TYPE              VALUE 
0000000000000000 SEGREL64LSB       .text
0000000000000008 SEGREL64LSB       .text+0x0000000000000020
0000000000000010 SEGREL64LSB       .IA_64.unwind_info


As a result, the final executable helldl will be different.

Note that in this case, the internal (bit-)representation of pointers to
void and pointers to functions is identical, but the linking behavior is
not.  I can even use a function declaration in one object and a variable
declaration in another, link both into one binary against a shared
library defining a function with this name, and the former passes
whereas the latter gives me either SIGSEGV or SIGILL.

But back to patching _LT_CMD_GLOBAL_SYMBOLS in m4/libtool.m4: my last
patch was suboptimal in that it should assume GNU ld and set symcode
appropriately.
BTW: is setting symcode differently after using some former value done
on purpose?  lt_cv_sys_global_symbol_to_c_name_address uses a default,
whereas global_symbol_to_cdecl and global_symbol_to_c_name_address use
system-specifics.

So, here goes my second try.  Questions open to me:
- Is assuming GNU ld ok here?
- Do weak symbols cause trouble with this approach?

I have tested my patch on both gcc-2.96 (from Debian stable) and
gcc-3.2, using GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux.

Comments of any kind very much welcome.  Thanks for reading.

Regards,
Ralf

2004-09-07  Ralf Wildenhues <address@hidden>

        * m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): The linker
        distinguishes data and code symbols on linux-gnu/ia64.
        Fixes multiple testsuite failures.

Index: m4/libtool.m4
===================================================================
RCS file: /cvsroot/libtool/libtool/m4/libtool.m4,v
retrieving revision 1.99
diff -u -r1.99 libtool.m4
--- m4/libtool.m4       5 Sep 2004 17:35:16 -0000       1.99
+++ m4/libtool.m4       7 Sep 2004 13:12:04 -0000
@@ -2717,6 +2717,13 @@
 irix* | nonstopux*)
   symcode='[[BCDEGRST]]'
   ;;
+linux*)
+  if test "$host_cpu" = ia64; then
+    symcode='[[ABCDGIRSTW]]'
+    lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int 
\1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
+    lt_cv_sys_global_symbol_to_c_name_address="sed -n -e 's/^: \([[^ ]]*\) $/  
{\\\"\1\\\", (void *) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  
{\"\2\", (void *) \&\2},/p'"
+  fi
+  ;;
 osf*)
   symcode='[[BCDEGQRST]]'
   ;;