public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Jie Zhang" <jzhang918@gmail.com>
To: binutils@sourceware.org
Cc: "Alexandre Oliva" <aoliva@redhat.com>,
	 	"Bernd Schmidt" <bernds_cb1@t-online.de>,
	 	"Alan Modra" <amodra@bigpond.net.au>
Subject: [PATCH, bfin] Clear relocs for removed entries in .eh_frame section
Date: Wed, 26 Apr 2006 09:29:00 -0000	[thread overview]
Message-ID: <6f48278f0604252045u3b055875v1a3e1e8bfab74a22@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

When debugging a C++ exception unwinding issue for Blackfin FDPIC
format, I found a bug of Blackfin BFD FDPIC support. When linking,
duplicate CIE will be removed from output .eh_frame section. But the
relocations for them are not. When dynamic linker does these
relocations, some contents in .eh_frame will be wrongly modified. This
causes the exception unwinding failure. I attached a patch for it. But
there are several points I'm not sure:

1. I saw this in elflink.c:elf_link_input_bfd ()

		      /* This is a reloc for a deleted entry or somesuch.
			 Turn it into an R_*_NONE reloc, at the same
			 offset as the last reloc.  elf_eh_frame.c and
			 elf_bfd_discard_info rely on reloc offsets
			 being ordered.  */

In my patch I just set the offset to zero. It seems works. I don't
know if we need do the same.

Alan: The comment was from you. Can you help me understand it?

2. In bfinfdpic_relocate_section () there are several calls to
_bfd_elf_section_offset () before calling _bfinfdpic_add_dyn_reloc ().
Only in one place the return value of _bfd_elf_section_offset () is
checked in my patch. It seems works. But I'm not sure if we need add
such check for all these calls.

3. Is it possible to not emit the reloc instead of set its type to R_*_NONE?

Alex: I think FRV has the same issue. In the lasted release of
redhat's frv toolchain from redhat's ftp, the bug is hidden since all
dupilicated CIEs are not optimized away because there is CIE format
incompatibility between gcc (3.4) and binutils (2.14).

Thanks,
Jie

[-- Attachment #2: bfin-fdpic-bfd-cie.diff --]
[-- Type: text/x-patch, Size: 1772 bytes --]

Index: elf32-bfin.c
===================================================================
RCS file: /cvsroot/gcc3/binutils/binutils-2.15/bfd/elf32-bfin.c,v
retrieving revision 1.35
diff -u -p -r1.35 elf32-bfin.c
--- elf32-bfin.c	6 Apr 2006 05:48:02 -0000	1.35
+++ elf32-bfin.c	24 Apr 2006 10:46:44 -0000
@@ -2476,6 +2481,8 @@ bfinfdpic_relocate_section (bfd * output
 						 input_section->output_section)
 			  & (SEC_ALLOC | SEC_LOAD)) == (SEC_ALLOC | SEC_LOAD))
 		  {
+		    bfd_vma offset;
+
 		    if (_bfinfdpic_osec_readonly_p (output_bfd,
 						   input_section
 						   ->output_section))
@@ -2486,15 +2493,23 @@ bfinfdpic_relocate_section (bfd * output
 			   name, input_bfd, input_section, rel->r_offset);
 			return FALSE;
 		      }
-		    _bfinfdpic_add_dyn_reloc (output_bfd,
-					      bfinfdpic_gotrel_section (info),
-					      _bfd_elf_section_offset
-					      (output_bfd, info,
-					       input_section, rel->r_offset)
-					      + input_section
-					      ->output_section->vma
-					      + input_section->output_offset,
-					      r_type, dynindx, addend, picrel);
+		    offset = _bfd_elf_section_offset (output_bfd, info,
+						      input_section, rel->r_offset);
+		    /* Only output a reloc for a not deleted entry.  */
+		    if (offset >= (bfd_vma) -2)
+		      _bfinfdpic_add_dyn_reloc (output_bfd,
+						bfinfdpic_gotrel_section (info),
+						0,
+						R_unused0,
+						dynindx, addend, picrel);
+		    else
+		      _bfinfdpic_add_dyn_reloc (output_bfd,
+						bfinfdpic_gotrel_section (info),
+						offset + input_section
+						->output_section->vma
+						+ input_section->output_offset,
+						r_type,
+						dynindx, addend, picrel);
 		  }
 		else
 		  addend += bfinfdpic_got_section (info)->output_section->vma;


             reply	other threads:[~2006-04-26  3:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-26  9:29 Jie Zhang [this message]
2006-04-26  9:34 ` Alan Modra
2006-04-27 16:42   ` Jie Zhang
2006-05-23  9:42 ` Jie Zhang

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=6f48278f0604252045u3b055875v1a3e1e8bfab74a22@mail.gmail.com \
    --to=jzhang918@gmail.com \
    --cc=amodra@bigpond.net.au \
    --cc=aoliva@redhat.com \
    --cc=bernds_cb1@t-online.de \
    --cc=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).