public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb AT cygnus.com>
To: Ian Lance Taylor <ian AT zembu.com>,
	kevinb AT cygnus.com, drepper AT cygnus.com, rth AT cygnus.com
Cc: gdb AT sourceware.cygnus.com, binutils AT sourceware.cygnus.com,
	jimb AT cygnus.com
Subject: Re: Zero valued N_FUN stabs in shared objects: Why?
Date: Mon, 13 Sep 1999 12:45:00 -0000	[thread overview]
Message-ID: <990913194452.ZM9564@ocotillo.lan> (raw)
In-Reply-To: <ian@zembu.com>

On Sep 10,  7:49pm, Ian Lance Taylor wrote:

>        Why do shared objects on Solaris and Linux have zero-valued
>        N_FUN stabs?
> 
> Good question.  It doesn't happen with binutils 2.9.1, but it does
> happen in the current development sources.
> 
> It's because of this bit of code in elf_i386_relocate_section in
> bfd/elf32-i386.c:
> 
> 			  /* DWARF will emit R_386_32 relocations in its
> 			     sections against symbols defined externally
> 			     in shared libraries.  We can't do anything
> 			     with them here.  */
> 			  || (input_section->flags & SEC_DEBUGGING) != 0)))
> 
> If I remove that, N_FUN stabs are no longer zero.

Good call.  I've tested your suggested change and it does indeed solve
the problems that I was seeing on Linux.  (The N_FUN stabs addresses
are no longer zero, and I no longer need to enable the
SOFUN_ADDRESS_MAYBE_MISSING hack in gdb to debug shared objects on
linux/x86.)

But Solaris/sparc is still broken...  Someone (I don't know who) gave
the patch below to Jim Blandy (for our customer to try), but it does
not cure the problem of the N_FUN stabs being zero.

Any ideas?

Kevin

Index: elf32-sparc.c
===================================================================
RCS file: /cvs/binutils/binutils/bfd/elf32-sparc.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 elf32-sparc.c
--- elf32-sparc.c	1999/05/03 07:28:56	1.1.1.1
+++ elf32-sparc.c	1999/05/17 03:54:39
@@ -1526,11 +1526,13 @@
 	      ++sreloc->reloc_count;
 
 	      /* This reloc will be computed at runtime, so there's no
-                 need to do anything now, unless this is a RELATIVE
-                 reloc in an unallocated section.  */
+                 need to do anything now.  However, if this is a
+                 RELATIVE or 32 reloc in an unallocated section, we
+                 resolve it now for the benefit of gdb.  */
 	      if (skip
 		  || (input_section->flags & SEC_ALLOC) != 0
-		  || ELF32_R_TYPE (outrel.r_info) != R_SPARC_RELATIVE)
+		  || (ELF32_R_TYPE (outrel.r_info) != R_SPARC_RELATIVE
+		      && ELF32_R_TYPE (outrel.r_info) != R_SPARC_32))
 		continue;
 	    }
 	  break;

      parent reply	other threads:[~1999-09-13 12:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-10 15:19 Kevin Buettner
1999-09-10 16:51 ` Ian Lance Taylor
1999-09-11  0:35   ` Richard Henderson
     [not found]   ` <ian@zembu.com>
1999-09-13 12:45     ` Kevin Buettner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=990913194452.ZM9564@ocotillo.lan \
    --to=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).