public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: "Alan Modra" <amodra@gmail.com>
Cc: <binutils@sourceware.org>
Subject: your change "bfd_find_nearest_line without debug info"
Date: Fri, 18 Oct 2013 07:27:00 -0000	[thread overview]
Message-ID: <5260FF1602000078000FBF97@nat28.tlf.novell.com> (raw)

Alan,

while I realize that this went in well over a year ago, I got puzzled
by the odd extra file symbols only pretty recently, in particular by
them accumulating in build models involving multiple levels of "ld -r"
(like Linux or Xen do). While I got the impression that one way to
deal with this would be to suppress emission of the extra symbols
generally for relocatable links, I think deferring the emission as
done below (tested on 2.23.2 only for now, but appears to apply
fine to mainline too) would cover an even broader range of cases,
and at the same time would take care of the eventual case of a
relocatable link also converting a global symbol to a local one.

Jan

--- binutils-2.23.2/bfd/elflink.c
+++ 2.23.2/bfd/elflink.c
@@ -7457,6 +7457,7 @@ struct elf_outext_info
   bfd_boolean localsyms;
   bfd_boolean need_second_pass;
   bfd_boolean second_pass;
+  bfd_boolean file_sym_done;
   struct elf_final_link_info *flinfo;
 };
 
@@ -8660,6 +8661,22 @@ elf_link_output_extsym (struct bfd_hash_
 		|| h->root.type == bfd_link_hash_defweak)
 	       && h->root.u.def.section->output_section != NULL))
 	return TRUE;
+
+      if (!eoinfo->file_sym_done
+	  && (eoinfo->second_pass ? eoinfo->flinfo->filesym_count == 1
+				  : eoinfo->flinfo->filesym_count > 1))
+	{
+	  /* Output a FILE symbol so that following locals are not associated
+	     with the wrong input file.  */
+	  memset (&sym, 0, sizeof (sym));
+	  sym.st_info = ELF_ST_INFO (STB_LOCAL, STT_FILE);
+	  sym.st_shndx = SHN_ABS;
+	  if (!elf_link_output_sym (eoinfo->flinfo, NULL, &sym,
+				    bfd_und_section_ptr, NULL))
+	    return FALSE;
+
+	  eoinfo->file_sym_done = TRUE;
+	}
     }
   else
     {
@@ -10907,17 +10924,6 @@ bfd_elf_final_link (bfd *abfd, struct bf
 	  }
     }
 
-  /* Output a FILE symbol so that following locals are not associated
-     with the wrong input file.  */
-  memset (&elfsym, 0, sizeof (elfsym));
-  elfsym.st_info = ELF_ST_INFO (STB_LOCAL, STT_FILE);
-  elfsym.st_shndx = SHN_ABS;
-
-  if (flinfo.filesym_count > 1
-      && !elf_link_output_sym (&flinfo, NULL, &elfsym,
-			       bfd_und_section_ptr, NULL))
-    return FALSE;
-
   /* Output any global symbols that got converted to local in a
      version script or due to symbol visibility.  We do this in a
      separate step since ELF requires all local symbols to appear
@@ -10929,15 +10935,11 @@ bfd_elf_final_link (bfd *abfd, struct bf
   eoinfo.localsyms = TRUE;
   eoinfo.need_second_pass = FALSE;
   eoinfo.second_pass = FALSE;
+  eoinfo.file_sym_done = FALSE;
   bfd_hash_traverse (&info->hash->table, elf_link_output_extsym, &eoinfo);
   if (eoinfo.failed)
     return FALSE;
 
-  if (flinfo.filesym_count == 1
-      && !elf_link_output_sym (&flinfo, NULL, &elfsym,
-			       bfd_und_section_ptr, NULL))
-    return FALSE;
-
   if (eoinfo.need_second_pass)
     {
       eoinfo.second_pass = TRUE;


             reply	other threads:[~2013-10-18  7:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-18  7:27 Jan Beulich [this message]
2013-10-18  8:13 ` Alan Modra

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=5260FF1602000078000FBF97@nat28.tlf.novell.com \
    --to=jbeulich@suse.com \
    --cc=amodra@gmail.com \
    --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).