All of lore.kernel.org
 help / color / mirror / Atom feed
* [parisc-linux] Problem with weak symbols
@ 2003-01-07 13:05 b.gunreben
  2003-01-07 17:47 ` John David Anglin
  2003-01-07 20:49 ` John David Anglin
  0 siblings, 2 replies; 7+ messages in thread
From: b.gunreben @ 2003-01-07 13:05 UTC (permalink / raw)
  To: parisc-linux

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:

> 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;
}

> ./weak
linux_bla: 0x205f0
linux_foo: (nil)

The main difference in compiling seems to be the different relocation
type for both symbols:

> 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] Problem with weak symbols
  2003-01-07 13:05 [parisc-linux] Problem with weak symbols b.gunreben
@ 2003-01-07 17:47 ` John David Anglin
  2003-01-07 17:51   ` John David Anglin
  2003-01-07 20:49 ` John David Anglin
  1 sibling, 1 reply; 7+ messages in thread
From: John David Anglin @ 2003-01-07 17:47 UTC (permalink / raw)
  To: b.gunreben; +Cc: parisc-linux

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 941 bytes --]

> 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 (".weak linux_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.

> extern const char * linux_bla;
> extern const int linux_foo[];

> > ./weak
> linux_bla: 0x205f0
> linux_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
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] Problem with weak symbols
  2003-01-07 17:47 ` John David Anglin
@ 2003-01-07 17:51   ` John David Anglin
  0 siblings, 0 replies; 7+ messages in thread
From: John David Anglin @ 2003-01-07 17:51 UTC (permalink / raw)
  To: John David Anglin; +Cc: b.gunreben, parisc-linux

> > > ./weak
> > linux_bla: 0x205f0
> > linux_foo: (nil)

Try "-fPIC".

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] Problem with weak symbols
  2003-01-07 13:05 [parisc-linux] Problem with weak symbols b.gunreben
  2003-01-07 17:47 ` John David Anglin
@ 2003-01-07 20:49 ` John David Anglin
  2003-01-07 22:49   ` b.gunreben
  1 sibling, 1 reply; 7+ messages in thread
From: John David Anglin @ 2003-01-07 20:49 UTC (permalink / raw)
  To: b.gunreben; +Cc: parisc-linux

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 2143 bytes --]

> 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
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2003-01-07  John David Anglin  <dave.anglin@nrc.gc.ca>

	* 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)))

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] Problem with weak symbols
  2003-01-07 20:49 ` John David Anglin
@ 2003-01-07 22:49   ` b.gunreben
  2003-01-07 23:10     ` Grant Grundler
  0 siblings, 1 reply; 7+ messages in thread
From: b.gunreben @ 2003-01-07 22:49 UTC (permalink / raw)
  To: John David Anglin; +Cc: parisc-linux

John David Anglin wrote:
> =

> > 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] Problem with weak symbols
  2003-01-07 22:49   ` b.gunreben
@ 2003-01-07 23:10     ` Grant Grundler
  2003-01-13  1:48       ` Andrew Shugg
  0 siblings, 1 reply; 7+ messages in thread
From: Grant Grundler @ 2003-01-07 23:10 UTC (permalink / raw)
  To: b.gunreben; +Cc: John David Anglin, parisc-linux

On Tue, Jan 07, 2003 at 11:49:49PM +0100, b.gunreben wrote:
> 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 <branden@debian.org>
...

grant

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [parisc-linux] Problem with weak symbols
  2003-01-07 23:10     ` Grant Grundler
@ 2003-01-13  1:48       ` Andrew Shugg
  0 siblings, 0 replies; 7+ messages in thread
From: Andrew Shugg @ 2003-01-13  1:48 UTC (permalink / raw)
  To: parisc-linux

Grant Grundler said:
> On Tue, Jan 07, 2003 at 11:49:49PM +0100, b.gunreben wrote:
> > 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 <branden@debian.org>
> ...
> 
> grant

The appropriate place for discussion of the Debian XFree86 packages is
probably the debian-x@lists.debian.org 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

-- 
Andrew Shugg <andrew@neep.com.au>                   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."

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2003-01-13  1:48 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-07 13:05 [parisc-linux] Problem with weak symbols b.gunreben
2003-01-07 17:47 ` John David Anglin
2003-01-07 17:51   ` John David Anglin
2003-01-07 20:49 ` John David Anglin
2003-01-07 22:49   ` b.gunreben
2003-01-07 23:10     ` Grant Grundler
2003-01-13  1:48       ` Andrew Shugg

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.