Problem with weak symbols
Hi,
I have a problem with weak symbols on parisc. If I use the following small program, the result should be always (nil), but it isn=B4t:
Quoted 1 line
cat
weak.c
#include <stdio.h>
#include <ctype.h>
=
asm (".weak linux_bla");
asm (".weak linux_foo");
=
extern const char * linux_bla;
extern const int linux_foo[];
=
int
main ()
{
printf("linux_bla: %p\n", &linux_bla);
printf("linux_foo: %p\n", &linux_foo);
return 0;
}
Quoted 1 line
./weak
linux_bla: 0x205f0linux_foo: (nil)
The main difference in compiling seems to be the different relocation type for both symbols:
Quoted 1 line
readelf -r weak.o
=
Relocation section '.rela.text' at offset 0x410 contains 10 entries:
Offset Info Type Symbol's Value Symbol's Name =
Addend
00000010 00502 R_PARISC_DIR21L 00000000 =
=2ELC0 + 0
00000014 00506 R_PARISC_DIR14R 00000000 =
=2ELC0 + 0
00000018 00912 R_PARISC_DPREL21L 00000000 =
linux_bla + 0
0000001c 00916 R_PARISC_DPREL14R 00000000 =
linux_bla + 0
00000020 00c0c R_PARISC_PCREL17F 00000000 =
printf + 0
00000028 00602 R_PARISC_DIR21L 00000010 =
=2ELC1 + 0
0000002c 00606 R_PARISC_DIR14R 00000010 =
=2ELC1 + 0
00000030 00a02 R_PARISC_DIR21L 00000000 =
linux_foo + 0
00000034 00a06 R_PARISC_DIR14R 00000000 =
linux_foo + 0
00000038 00c0c R_PARISC_PCREL17F 00000000 =
printf + 0
I am currently using gcc version 3.2.1, binutils version 2.13.90.0.16 20021126, glibc version 2.3.1, but I had this problem already with gcc 3.0.4 and all compilers inbetween. Is there a possibility to work around this?
Berthold
Quoted 7 lines
Hi,
I have a problem with weak symbols on parisc. If I use the following small program, the result should be always (nil), but it isn´t:
asm (".weak
linux_bla");
asm (".weaklinux_foo");
Don't use asm's to weaken symbols. Use GCC's attribute weak. GCC needs to know whether a symbol is weak or not.
Quoted 9 lines
extern const char *
linux_bla;
extern const int linux_foo[];Quoted 1 line
./weak
linux_bla:0x205f0linux_foo: (nil)The main difference in compiling seems to be the different relocation type for both symbols:
What is printed in the first case is the value of the $dp register. For some reason, $global$ is not being subtracted from the symbol value (zero). This is a linker bug, not a gcc bug.
We probably should be using DPREL relocations for linux_foo.
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
./weak
linux_bla:0x205f0linux_foo: (nil)
Try "-fPIC".
Dave
Signature · 2 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
Quoted 2 lines
I have a problem with weak symbols on parisc. If I use the following small program, the result should be always (nil), but it isn´t:
I believe the enclosed binutils patch will fix the problem. I will install it after a little more testing.
Dave
Signature · 37 lines
J. David Anglin [email protected] National Research Council of Canada (613) 990-0752 (FAX: 952-6605) 2003-01-07 John David Anglin <[email protected]> * elf32-hppa.c (final_link_relocate): For all DP relative relocations, adjust addil instructions if the symbol has no section. Index: elf32-hppa.c =================================================================== RCS file: /cvs/src/src/bfd/elf32-hppa.c,v retrieving revision 1.92 diff -u -3 -p -r1.92 elf32-hppa.c --- elf32-hppa.c 12 Dec 2002 10:17:14 -0000 1.92 +++ elf32-hppa.c 7 Jan 2003 20:15:48 -0000 @@ -3416,15 +3416,14 @@ final_link_relocate (input_section, cont case R_PARISC_DPREL14R: case R_PARISC_DPREL14F: /* For all the DP relative relocations, we need to examine the symbol's - section. If it's a code section, then "data pointer relative" makes - no sense. In that case we don't adjust the "value", and for 21 bit - addil instructions, we change the source addend register from %dp to - %r0. This situation commonly arises when a variable's "constness" + section. If it has no section or if it's a code section, then + "data pointer relative" makes no sense. In that case we don't + adjust the "value", and for 21 bit addil instructions, we change the + source addend register from %dp to %r0. This situation commonly + arises for undefined weak symbols and when a variable's "constness" is declared differently from the way the variable is defined. For instance: "extern int foo" with foo defined as "const int foo". */ - if (sym_sec == NULL) - break; - if ((sym_sec->flags & SEC_CODE) != 0) + if (sym_sec == NULL || (sym_sec->flags & SEC_CODE) != 0) { if ((insn & ((0x3f << 26) | (0x1f << 21))) == (((int) OP_ADDIL << 26) | (27 << 21)))
Quoted 8 lines · John David Anglin
=
Quoted 2 lines
I have a problem with weak symbols on parisc. If I use the following small program, the result should be always (nil), but it isn=B4t:
=
I believe the enclosed binutils patch will fix the problem. I will install it after a little more testing.
Thanks, I will try this. If someone knows who is maintaining the XFree86 package of debian, this is the reason why imake does not detect the glibc=
correctly. I tried to debug it myself, but at this point I was stuck. =
This was a fast bugfix:) Thank you
Berthold
Quoted 1 line · b.gunreben
If someone knows who is maintaining the XFree86 package of debian,
I recently asked the same question:
apt-cache show xfree86-common
...
Maintainer: Branden Robinson <[email protected]>
...
grant
Quoted 10 lines · Grant Grundler
Quoted 1 line · b.gunreben
If someone knows who is maintaining the XFree86 package of debian,
I recently asked the same question:
apt-cache show xfree86-common
...
Maintainer: Branden Robinson <[email protected]>
...grant
The appropriate place for discussion of the Debian XFree86 packages is probably the [email protected] mailing list[1], home of The X Strike Force[2]. =)
Andrew.
[1] http://lists.debian.org/debian-x/
[2] http://people.debian.org/~branden/xsf/xsf.html
Signature · 4 lines
Andrew Shugg <[email protected]> http://www.neep.com.au/ "Just remember, Mr Fawlty, there's always someone worse off than yourself." "Is there? Well I'd like to meet him. I could do with a good laugh."