binutils-2.17: --cref broken? Extra warnings and corrupted data

binutils-2.17: --cref broken? Extra warnings and corrupted data

[Paul Nash]

Hello all,

I've done my best to narrow this down somewhat, but I'm not sure it's
good enough for Bugzilla yet.  I hope someone can help who knows more
about the internals of BFD and what's really supposed to be happening
here. It looks to me like memory is getting stepped on.

Note, this does not happen with various other versions of binutils
that I've tried, most certainly the binutils-2.17-pre CSL release.

I am seeing a situation where linking any binary with binutils-2.17 ld
using the --cref option causes lots of "symbol 'blah' missing from
main hash table" warnings.  The "blah" in these cases is complete
garbage.

I determined with gdb that at the time add_cref is called,
h->root.string is a valid string pointer.  What's causing the problem
is that later when the cref table is output, the underlying memory
behind that pointer has been corrupted. In one case I looked at, a
later bfd_zalloc call memset's all the memory around that string to 0.

It seems like a potentially simple fix would be to have add_cref copy
the string when inserting into its hash table. But I assume the reason
it does not do this is because the string is supposed to be valid and
unchanging in the presumed lifetime of the cref hash table, so why
waste the memory to copy.  So I'm reluctant to implement this hack
without understanding the cause.  But, knowing where this string is
really allocated and where it might be freed is beyond my bfd/ld
knowledge. :-(

 Details
 ----------

 I built binutils-2.17 from pur sources, configured like this:

    .././binutils-2.17/configure  --prefix=/usr/local/i686/4.1.1-1b
--enable-shared --with-lib-path=/usr/local/i686/4.1.1-1b/lib

 A few small cross-arm patches are present, but I've got same results
without those.  It was built using gcc-4.1.1.

 I can compile a very very simple test program, for example let's say
I main a file with:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char* argv[])
{
   printf("Hello cref!\n");
}

Now I compile this with: "gcc -c -o test.o test.c"

Now I link with: "ld --cref -o test -lc test.o"

And what will happen in my build is that a bunch of errors come out:

Cross Reference Table

Symbol                                            File
/tmp/ld-new: symbol `no symbol' missing from main hash table

/usr/local/i686/4.1.1-1b/lib/ld-linux.so.2
/tmp/ld-new: symbol `no symbol' missing from main hash table

/usr/local/i686/4.1.1-1b/lib/ld-linux.so.2
/tmp/ld-new: symbol `no symbol' missing from main hash table

/usr/local/i686/4.1.1-1b/lib/ld-linux.so.2
/tmp/ld-new: symbol `no symbol' missing from main hash table

/usr/local/i686/4.1.1-1b/lib/ld-linux.so.2
/tmp/ld-new: symbol `x\uffff8\uffff' missing from main hash table
x\uffff8\uffff
/usr/local/i686/4.1.1-1b/lib/ld-linux.so.2


 -----> Here's what I found on one symbol I know has this problem in
my test exe:

 Breakpoint 3, add_cref (name=0x81be448
"_dl_allocate_tls_init@GLIBC_PRIVATE", abfd=0x80e7818,
section=0xb7f03b80, value=0)
     at ldcref.c:159
 159       if (h == NULL)
 (gdb) enable 6 7 8
 (gdb) c

 ------> So here we can see that name==0x81be448, and it's a valid
string. So I set a watchpoint for memory at that location to change
and, sure enough:

 (gdb) watch *0x81be448
 Hardware watchpoint 4: *136045640
 (gdb) c
 Continuing.
 Hardware watchpoint 4: *136045640

 Old value = 1600939103
 New value = 0
 0xb7dd3987 in memset () from /usr/local/i686/4.1.1-1b/lib/libc.so.6
 (gdb) bt
 #0  0xb7dd3987 in memset () from /usr/local/i686/4.1.1-1b/lib/libc.so.6
 #1  0xb7ea3ac4 in bfd_zalloc (abfd=0x80efae0, size=748) at opncls.c:926
 #2  0xb7eb8f2b in elf_i386_mkobject (abfd=0x80efae0) at elf32-i386.c:630
 #3  0xb7ebc98c in bfd_elf32_object_p (abfd=0x80efae0) at elfcode.h:547
 #4  0xb7ea1de3 in bfd_check_format_matches (abfd=0x80efae0,
format=bfd_object, matching=0xbfd23c6c) at format.c:169
 #5  0x080555b4 in load_symbols (entry=0x80a20c0, place=0xbfd23cbc) at
ldlang.c:2323
 #6  0x080562ad in open_input_bfds (s=0x80a20c0, force=0) at ldlang.c:2852
 #7  0x0805a1de in lang_process () at ldlang.c:5476
 #8  0x0805da28 in main (argc=6, argv=0xbfd23e54) at ldmain.c:459

 Help?

 -PN

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[Alan Modra]

On Sat, Jul 15, 2006 at 11:41:23PM -0700, Paul Nash wrote:
> I determined with gdb that at the time add_cref is called,
> h->root.string is a valid string pointer.  What's causing the problem
> is that later when the cref table is output, the underlying memory
> behind that pointer has been corrupted. In one case I looked at, a
> later bfd_zalloc call memset's all the memory around that string to 0.

Try reverting HJ's 2006-04-25 patch.
http://sources.redhat.com/ml/binutils/2006-04/msg00095.html

Please let us know if this fixes the problem for you.  There are likely
to be other serious problems besides the --cref one.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[H. J. Lu]

On Mon, Jul 17, 2006 at 11:33:50AM +0930, Alan Modra wrote:
> On Sat, Jul 15, 2006 at 11:41:23PM -0700, Paul Nash wrote:
> > I determined with gdb that at the time add_cref is called,
> > h->root.string is a valid string pointer.  What's causing the problem
> > is that later when the cref table is output, the underlying memory
> > behind that pointer has been corrupted. In one case I looked at, a
> > later bfd_zalloc call memset's all the memory around that string to 0.
> 
> Try reverting HJ's 2006-04-25 patch.
> http://sources.redhat.com/ml/binutils/2006-04/msg00095.html
> 
> Please let us know if this fixes the problem for you.  There are likely
> to be other serious problems besides the --cref one.

--cref was broken by --as-needed. cref stores the string pointer from
a dso. When memory of unused dso is freed, cref reference is corrupted.


H.J.

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[H. J. Lu]

On Mon, Jul 17, 2006 at 03:30:53PM -0700, H. J. Lu wrote:
> On Mon, Jul 17, 2006 at 11:33:50AM +0930, Alan Modra wrote:
> > On Sat, Jul 15, 2006 at 11:41:23PM -0700, Paul Nash wrote:
> > > I determined with gdb that at the time add_cref is called,
> > > h->root.string is a valid string pointer.  What's causing the problem
> > > is that later when the cref table is output, the underlying memory
> > > behind that pointer has been corrupted. In one case I looked at, a
> > > later bfd_zalloc call memset's all the memory around that string to 0.
> > 
> > Try reverting HJ's 2006-04-25 patch.
> > http://sources.redhat.com/ml/binutils/2006-04/msg00095.html
> > 
> > Please let us know if this fixes the problem for you.  There are likely
> > to be other serious problems besides the --cref one.
> 
> --cref was broken by --as-needed. cref stores the string pointer from
> a dso. When memory of unused dso is freed, cref reference is corrupted.

I opened a bug report:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=2939


H.J.

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[Alan Modra]

On Mon, Jul 17, 2006 at 03:30:53PM -0700, H. J. Lu wrote:
> --cref was broken by --as-needed.

Ah.  My bug then.

> cref stores the string pointer from
> a dso. When memory of unused dso is freed, cref reference is corrupted.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[Paul R. Nash]

On 7/16/06, Alan Modra <amodra@bigpond.net.au> wrote:
> On Sat, Jul 15, 2006 at 11:41:23PM -0700, Paul Nash wrote:
> > I determined with gdb that at the time add_cref is called,
> > h->root.string is a valid string pointer.  What's causing the problem
> > is that later when the cref table is output, the underlying memory
> > behind that pointer has been corrupted. In one case I looked at, a
> > later bfd_zalloc call memset's all the memory around that string to 0.
>
> Try reverting HJ's 2006-04-25 patch.
> http://sources.redhat.com/ml/binutils/2006-04/msg00095.html
>
> Please let us know if this fixes the problem for you.  There are likely
> to be other serious problems besides the --cref one.

Oops, I looked away for a day or two, sorry. Anyway, it sounds like
H.J. figured it out.  Is the above referenced patch still suspect?
Should I try to remove that in general?

I'd be happy to verify any fixes you come up with, Alan.

Incidentally, I did test my theory of changing the "copy" flag to true
on cref hash table insertion, and that did appear to fix the problem,
but maybe that's just fixing a symptom, I don't know. Maybe there are
other places that also could be bitten by accessing invalid memory.

-PN

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[Paul R. Nash]

On 7/17/06, Alan Modra <amodra@bigpond.net.au> wrote:
> On Mon, Jul 17, 2006 at 03:30:53PM -0700, H. J. Lu wrote:
> > --cref was broken by --as-needed.
>
> Ah.  My bug then.
>
> > cref stores the string pointer from
> > a dso. When memory of unused dso is freed, cref reference is corrupted.

One note about this, in reading the bug report for pr/2939 I'm unsure
that the discussed scenario actually matches my test case, but you
guys are the experts. To be clear though, I have not explicitly used
the --as-needed flags in my repro case.  In the example H.J. gives in
the bug, the symbol in the "missing from main hash" error message is
still a valid string, so it doesn't fully iilustrate that the pointer
is in fact dangling and in many cases will be a garbage string.

Anyway...just wanted to make sure we're really talking about the same thing. :-)

Thanks all...

-PN

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[Andreas Schwab]

"Paul R. Nash" <nashpaulr@gmail.com> writes:

> To be clear though, I have not explicitly used
> the --as-needed flags in my repro case.

You did implicitly, by linking against libc.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[Alan Modra]

On Tue, Jul 18, 2006 at 12:34:09PM +0930, Alan Modra wrote:
> On Mon, Jul 17, 2006 at 03:30:53PM -0700, H. J. Lu wrote:
> > --cref was broken by --as-needed.
> 
> Ah.  My bug then.

This extends the horrible hack of saving the main symbol table to saving
the cref table too.  I'm not proud at all of this hack for --as-needed.
Some day when I have a some time on my hands I'll look at implementing
a two-pass approach to loading --as-needed library syms.

bfd/
	* bfd-in.h (enum notice_asneeded_action): Define.
	* bfd-in2.h: Regenerate.
	* elflink.c (elf_link_add_object_symbols): Call linker "notice"
	function with NULL name for as-needed handling.
ld/
	* ld.h (handle_asneeded_cref): Declare.
	* ldcref.c: Include objalloc.h.
	(old_table, old_count, old_tab, alloc_mark): New variables.
	(tabsize, entsize, refsize, old_symcount): Likewise.
	(add_cref): Use bfd_hash_allocate for refs.
	(handle_asneeded_cref): New function.
	* ldmain.c (notice): Call handle_asneeded_cref for NULL name.

Index: bfd/bfd-in.h
===================================================================
RCS file: /cvs/src/src/bfd/bfd-in.h,v
retrieving revision 1.115
diff -u -p -r1.115 bfd-in.h
--- bfd/bfd-in.h	15 May 2006 19:57:34 -0000	1.115
+++ bfd/bfd-in.h	18 Jul 2006 11:15:14 -0000
@@ -638,6 +638,12 @@ enum dynamic_lib_link_class {
   DYN_NO_NEEDED = 8
 };
 
+enum notice_asneeded_action {
+  notice_as_needed,
+  notice_not_needed,
+  notice_needed
+};
+
 extern bfd_boolean bfd_elf_record_link_assignment
   (bfd *, struct bfd_link_info *, const char *, bfd_boolean,
    bfd_boolean);
Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.224
diff -u -p -r1.224 elflink.c
--- bfd/elflink.c	14 Jul 2006 13:48:06 -0000	1.224
+++ bfd/elflink.c	18 Jul 2006 11:15:39 -0000
@@ -3551,6 +3551,13 @@ elf_link_add_object_symbols (bfd *abfd, 
       if (alloc_mark == NULL)
 	goto error_free_vers;
 
+      /* Make a special call to the linker "notice" function to
+	 tell it that we are about to handle an as-needed lib.  */
+      if (!(*info->callbacks->notice) (info, NULL, abfd, NULL,
+				       notice_as_needed))
+	return FALSE;
+
+
       /* Clone the symbol table and sym hashes.  Remember some
 	 pointers into the symbol table, and dynamic symbol count.  */
       old_hash = (char *) old_tab + tabsize;
@@ -4241,6 +4248,12 @@ elf_link_add_object_symbols (bfd *abfd, 
 	    }
 	}
 
+      /* Make a special call to the linker "notice" function to
+	 tell it that symbols added for crefs may need to be removed.  */
+      if (!(*info->callbacks->notice) (info, NULL, abfd, NULL,
+				       notice_not_needed))
+	return FALSE;
+
       free (old_tab);
       objalloc_free_block ((struct objalloc *) htab->root.table.memory,
 			   alloc_mark);
@@ -4251,6 +4264,9 @@ elf_link_add_object_symbols (bfd *abfd, 
 
   if (old_tab != NULL)
     {
+      if (!(*info->callbacks->notice) (info, NULL, abfd, NULL,
+				       notice_needed))
+	return FALSE;
       free (old_tab);
       old_tab = NULL;
     }
Index: ld/ld.h
===================================================================
RCS file: /cvs/src/src/ld/ld.h,v
retrieving revision 1.31
diff -u -p -r1.31 ld.h
--- ld/ld.h	30 May 2006 16:45:31 -0000	1.31
+++ ld/ld.h	18 Jul 2006 11:16:11 -0000
@@ -288,6 +288,7 @@ extern int parsing_defsym;
 
 extern int yyparse (void);
 extern void add_cref (const char *, bfd *, asection *, bfd_vma);
+extern bfd_boolean handle_asneeded_cref (bfd *, enum notice_asneeded_action);
 extern void output_cref (FILE *);
 extern void check_nocrossrefs (void);
 extern void ld_abort (const char *, int, const char *) ATTRIBUTE_NORETURN;
Index: ld/ldcref.c
===================================================================
RCS file: /cvs/src/src/ld/ldcref.c,v
retrieving revision 1.14
diff -u -p -r1.14 ldcref.c
--- ld/ldcref.c	16 Mar 2006 12:20:16 -0000	1.14
+++ ld/ldcref.c	18 Jul 2006 11:16:12 -0000
@@ -27,6 +27,7 @@ Foundation, Inc., 51 Franklin Street - F
 #include "sysdep.h"
 #include "bfdlink.h"
 #include "libiberty.h"
+#include "objalloc.h"
 
 #include "ld.h"
 #include "ldmain.h"
@@ -101,6 +102,16 @@ static bfd_boolean cref_initialized;
 
 static size_t cref_symcount;
 
+/* Used to take a snapshot of the cref hash table when starting to
+   add syms from an as-needed library.  */
+static struct bfd_hash_entry **old_table;
+static unsigned int old_size;
+static unsigned int old_count;
+static void *old_tab;
+static void *alloc_mark;
+static size_t tabsize, entsize, refsize;
+static size_t old_symcount;
+
 /* Create an entry in a cref hash table.  */
 
 static struct bfd_hash_entry *
@@ -165,7 +176,9 @@ add_cref (const char *name,
 
   if (r == NULL)
     {
-      r = xmalloc (sizeof *r);
+      r = bfd_hash_allocate (&cref_table.root, sizeof *r);
+      if (r == NULL)
+	einfo (_("%X%P: cref alloc failed: %E\n"));
       r->next = h->refs;
       h->refs = r;
       r->abfd = abfd;
@@ -182,6 +195,125 @@ add_cref (const char *name,
     r->def = TRUE;
 }
 
+/* Called before loading an as-needed library to take a snapshot of
+   the cref hash table, and after we have loaded or found that the
+   library was not needed.  */
+
+bfd_boolean
+handle_asneeded_cref (bfd *abfd ATTRIBUTE_UNUSED,
+		      enum notice_asneeded_action act)
+{
+  unsigned int i;
+
+  if (!cref_initialized)
+    return TRUE;
+
+  if (act == notice_as_needed)
+    {
+      char *old_ent, *old_ref;
+
+      for (i = 0; i < cref_table.root.size; i++)
+	{
+	  struct bfd_hash_entry *p;
+	  struct cref_hash_entry *c;
+	  struct cref_ref *r;
+
+	  for (p = cref_table.root.table[i]; p != NULL; p = p->next)
+	    {
+	      entsize += cref_table.root.entsize;
+	      c = (struct cref_hash_entry *) p;
+	      for (r = c->refs; r != NULL; r = r->next)
+		refsize += sizeof (struct cref_hash_entry);
+	    }
+	}
+
+      tabsize = cref_table.root.size * sizeof (struct bfd_hash_entry *);
+      old_tab = xmalloc (tabsize + entsize + refsize);
+
+      alloc_mark = bfd_hash_allocate (&cref_table.root, 1);
+      if (alloc_mark == NULL)
+	return FALSE;
+
+      memcpy (old_tab, cref_table.root.table, tabsize);
+      old_ent = (char *) old_tab + tabsize;
+      old_ref = (char *) old_ent + entsize;
+      old_table = cref_table.root.table;
+      old_size = cref_table.root.size;
+      old_count = cref_table.root.count;
+      old_symcount = cref_symcount;
+
+      for (i = 0; i < cref_table.root.size; i++)
+	{
+	  struct bfd_hash_entry *p;
+	  struct cref_hash_entry *c;
+	  struct cref_ref *r;
+
+	  for (p = cref_table.root.table[i]; p != NULL; p = p->next)
+	    {
+	      memcpy (old_ent, p, cref_table.root.entsize);
+	      old_ent = (char *) old_ent + cref_table.root.entsize;
+	      c = (struct cref_hash_entry *) p;
+	      for (r = c->refs; r != NULL; r = r->next)
+		{
+		  memcpy (old_ref, r, sizeof (struct cref_hash_entry));
+		  old_ref = (char *) old_ref + sizeof (struct cref_hash_entry);
+		}
+	    }
+	}
+      return TRUE;
+    }
+
+  if (act == notice_not_needed)
+    {
+      char *old_ent, *old_ref;
+
+      if (old_tab == NULL)
+	{
+	  /* The only way old_tab can be NULL is if the cref hash table
+	     had not been initialised when notice_as_needed.  */
+	  bfd_hash_table_free (&cref_table.root);
+	  cref_initialized = FALSE;
+	  return TRUE;
+	}
+
+      old_ent = (char *) old_tab + tabsize;
+      old_ref = (char *) old_ent + entsize;
+      cref_table.root.table = old_table;
+      cref_table.root.size = old_size;
+      cref_table.root.count = old_count;
+      memcpy (cref_table.root.table, old_tab, tabsize);
+      cref_symcount = old_symcount;
+
+      for (i = 0; i < cref_table.root.size; i++)
+	{
+	  struct bfd_hash_entry *p;
+	  struct cref_hash_entry *c;
+	  struct cref_ref *r;
+
+	  for (p = cref_table.root.table[i]; p != NULL; p = p->next)
+	    {
+	      memcpy (p, old_ent, cref_table.root.entsize);
+	      old_ent = (char *) old_ent + cref_table.root.entsize;
+	      c = (struct cref_hash_entry *) p;
+	      for (r = c->refs; r != NULL; r = r->next)
+		{
+		  memcpy (r, old_ref, sizeof (struct cref_hash_entry));
+		  old_ref = (char *) old_ref + sizeof (struct cref_hash_entry);
+		}
+	    }
+	}
+
+      objalloc_free_block ((struct objalloc *) cref_table.root.memory,
+			   alloc_mark);
+    }
+  else if (act != notice_needed)
+    return FALSE;
+
+  free (old_tab);
+  old_tab = NULL;
+  return TRUE;
+}
+
 /* Copy the addresses of the hash table entries into an array.  This
    is called via cref_hash_traverse.  We also fill in the demangled
    name.  */
Index: ld/ldmain.c
===================================================================
RCS file: /cvs/src/src/ld/ldmain.c,v
retrieving revision 1.108
diff -u -p -r1.108 ldmain.c
--- ld/ldmain.c	10 Jul 2006 21:40:22 -0000	1.108
+++ ld/ldmain.c	18 Jul 2006 11:16:12 -0000
@@ -1523,6 +1523,13 @@ notice (struct bfd_link_info *info,
 	asection *section,
 	bfd_vma value)
 {
+  if (name == NULL)
+    {
+      if (command_line.cref || nocrossref_list != NULL)
+	return handle_asneeded_cref (abfd, value);
+      return TRUE;
+    }
+
   if (! info->notice_all
       || (info->notice_hash != NULL
 	  && bfd_hash_lookup (info->notice_hash, name, FALSE, FALSE) != NULL))

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[Paul R. Nash]

On 7/18/06, Alan Modra <amodra@bigpond.net.au> wrote:
> On Tue, Jul 18, 2006 at 12:34:09PM +0930, Alan Modra wrote:
> > On Mon, Jul 17, 2006 at 03:30:53PM -0700, H. J. Lu wrote:
> > > --cref was broken by --as-needed.
> >
> > Ah.  My bug then.
>
> This extends the horrible hack of saving the main symbol table to saving
> the cref table too.  I'm not proud at all of this hack for --as-needed.
> Some day when I have a some time on my hands I'll look at implementing
> a two-pass approach to loading --as-needed library syms.
>

Attempting to build this on 2.17, I encountered two problems:

1) I had to figure out bfd-in2.h so I could put that in my patch
against the dist tarball. That wasn't hard, I got around it.

2) After that, building yields:

gcc -DHAVE_CONFIG_H -I. -I../.././binutils-2.17/binutils -I.
-D_GNU_SOURCE -I. -I../.././binutils-2.17/binutils -I../bfd
-I../.././binutils-2.17/binutils/../bfd
-I../.././binutils-2.17/binutils/../include
-I../.././binutils-2.17/binutils/../intl -I../intl
-DLOCALEDIR="\"/usr/local/i686/4.1.1-1b/share/locale\""
-Dbin_dummy_emulation=bin_vanilla_emulation   -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -pipe
-fno-stack-protector  -c ../.././binutils-2.17/binutils/size.c
gcc -DHAVE_CONFIG_H -I. -I../.././binutils-2.17/gas -I. -D_GNU_SOURCE
-I. -I../.././binutils-2.17/gas -I../bfd
-I../.././binutils-2.17/gas/config
-I../.././binutils-2.17/gas/../include -I../.././binutils-2.17/gas/..
-I../.././binutils-2.17/gas/../bfd -I../.././binutils-2.17/gas/../intl
-I../intl -DLOCALEDIR="\"/usr/local/i686/4.1.1-1b/share/locale\""   -W
-Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -O2 -pipe
-fno-stack-protector  -c ../.././binutils-2.17/gas/output-file.c
../.././binutils-2.17/ld/ldcref.c: In function `handle_asneeded_cref':
../.././binutils-2.17/ld/ldcref.c:242: error: structure has no member
named `count'
../.././binutils-2.17/ld/ldcref.c:283: error: structure has no member
named `count'
make[4]: *** [ldcref.o] Error 1

Indeed, there is no count in my version of struct
bfd_hash_table...actually there's no other usage of ".count" anywhere
in ld at least. Is that mainline only?

Thx...

-PN

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[Alan Modra]

On Tue, Jul 18, 2006 at 08:44:31PM -0700, Paul R. Nash wrote:
> ../.././binutils-2.17/ld/ldcref.c: In function `handle_asneeded_cref':
> ../.././binutils-2.17/ld/ldcref.c:242: error: structure has no member
> named `count'
> ../.././binutils-2.17/ld/ldcref.c:283: error: structure has no member
> named `count'
> make[4]: *** [ldcref.o] Error 1
> 
> Indeed, there is no count in my version of struct
> bfd_hash_table...actually there's no other usage of ".count" anywhere
> in ld at least. Is that mainline only?

Yes, you need a slightly different patch for 2.17.  Just delete all
occurrences of old_count in the patch you have, or pull the 2.17 version
from CVS binutils-2_17-branch.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: binutils-2.17: --cref broken? Extra warnings and corrupted data

[Paul R. Nash]

On 7/18/06, Alan Modra <amodra@bigpond.net.au> wrote:
> On Tue, Jul 18, 2006 at 08:44:31PM -0700, Paul R. Nash wrote:
> > ../.././binutils-2.17/ld/ldcref.c: In function `handle_asneeded_cref':
> > ../.././binutils-2.17/ld/ldcref.c:242: error: structure has no member
> > named `count'
> > ../.././binutils-2.17/ld/ldcref.c:283: error: structure has no member
> > named `count'
> > make[4]: *** [ldcref.o] Error 1
> >
> > Indeed, there is no count in my version of struct
> > bfd_hash_table...actually there's no other usage of ".count" anywhere
> > in ld at least. Is that mainline only?
>
> Yes, you need a slightly different patch for 2.17.  Just delete all
> occurrences of old_count in the patch you have, or pull the 2.17 version
> from CVS binutils-2_17-branch.

Oh -- duh, I didn't realize the patch was in CVS already (not on that list)!

Okay, I applied this and rebuilt my toolchain, and everything is
working much better!

Thanks all...

-PN