* binutils-2.17: --cref broken? Extra warnings and corrupted data @ 2006-07-16 6:41 Paul Nash 2006-07-17 2:03 ` Alan Modra 0 siblings, 1 reply; 12+ messages in thread From: Paul Nash @ 2006-07-16 6:41 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-16 6:41 binutils-2.17: --cref broken? Extra warnings and corrupted data Paul Nash @ 2006-07-17 2:03 ` Alan Modra 2006-07-17 22:30 ` H. J. Lu 2006-07-18 16:08 ` Paul R. Nash 0 siblings, 2 replies; 12+ messages in thread From: Alan Modra @ 2006-07-17 2:03 UTC (permalink / raw) To: Paul Nash; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-17 2:03 ` Alan Modra @ 2006-07-17 22:30 ` H. J. Lu 2006-07-17 22:53 ` H. J. Lu 2006-07-18 3:04 ` Alan Modra 2006-07-18 16:08 ` Paul R. Nash 1 sibling, 2 replies; 12+ messages in thread From: H. J. Lu @ 2006-07-17 22:30 UTC (permalink / raw) To: Paul Nash, binutils 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-17 22:30 ` H. J. Lu @ 2006-07-17 22:53 ` H. J. Lu 2006-07-18 3:04 ` Alan Modra 1 sibling, 0 replies; 12+ messages in thread From: H. J. Lu @ 2006-07-17 22:53 UTC (permalink / raw) To: Paul Nash, binutils 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-17 22:30 ` H. J. Lu 2006-07-17 22:53 ` H. J. Lu @ 2006-07-18 3:04 ` Alan Modra 2006-07-18 16:28 ` Paul R. Nash 2006-07-19 1:54 ` Alan Modra 1 sibling, 2 replies; 12+ messages in thread From: Alan Modra @ 2006-07-18 3:04 UTC (permalink / raw) To: H. J. Lu; +Cc: Paul Nash, binutils 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-18 3:04 ` Alan Modra @ 2006-07-18 16:28 ` Paul R. Nash 2006-07-18 17:20 ` Andreas Schwab 2006-07-19 1:54 ` Alan Modra 1 sibling, 1 reply; 12+ messages in thread From: Paul R. Nash @ 2006-07-18 16:28 UTC (permalink / raw) To: H. J. Lu, Paul Nash, binutils 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-18 16:28 ` Paul R. Nash @ 2006-07-18 17:20 ` Andreas Schwab 0 siblings, 0 replies; 12+ messages in thread From: Andreas Schwab @ 2006-07-18 17:20 UTC (permalink / raw) To: Paul R. Nash; +Cc: H. J. Lu, binutils "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." ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-18 3:04 ` Alan Modra 2006-07-18 16:28 ` Paul R. Nash @ 2006-07-19 1:54 ` Alan Modra 2006-07-19 3:44 ` Paul R. Nash 1 sibling, 1 reply; 12+ messages in thread From: Alan Modra @ 2006-07-19 1:54 UTC (permalink / raw) To: H. J. Lu, Paul Nash, binutils 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-19 1:54 ` Alan Modra @ 2006-07-19 3:44 ` Paul R. Nash 2006-07-19 4:23 ` Alan Modra 0 siblings, 1 reply; 12+ messages in thread From: Paul R. Nash @ 2006-07-19 3:44 UTC (permalink / raw) To: H. J. Lu, Paul Nash, binutils 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-19 3:44 ` Paul R. Nash @ 2006-07-19 4:23 ` Alan Modra 2006-07-19 16:33 ` Paul R. Nash 0 siblings, 1 reply; 12+ messages in thread From: Alan Modra @ 2006-07-19 4:23 UTC (permalink / raw) To: Paul R. Nash; +Cc: H. J. Lu, binutils 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-19 4:23 ` Alan Modra @ 2006-07-19 16:33 ` Paul R. Nash 0 siblings, 0 replies; 12+ messages in thread From: Paul R. Nash @ 2006-07-19 16:33 UTC (permalink / raw) To: binutils 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: binutils-2.17: --cref broken? Extra warnings and corrupted data 2006-07-17 2:03 ` Alan Modra 2006-07-17 22:30 ` H. J. Lu @ 2006-07-18 16:08 ` Paul R. Nash 1 sibling, 0 replies; 12+ messages in thread From: Paul R. Nash @ 2006-07-18 16:08 UTC (permalink / raw) To: Paul Nash, binutils 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2006-07-19 16:33 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-07-16 6:41 binutils-2.17: --cref broken? Extra warnings and corrupted data Paul Nash 2006-07-17 2:03 ` Alan Modra 2006-07-17 22:30 ` H. J. Lu 2006-07-17 22:53 ` H. J. Lu 2006-07-18 3:04 ` Alan Modra 2006-07-18 16:28 ` Paul R. Nash 2006-07-18 17:20 ` Andreas Schwab 2006-07-19 1:54 ` Alan Modra 2006-07-19 3:44 ` Paul R. Nash 2006-07-19 4:23 ` Alan Modra 2006-07-19 16:33 ` Paul R. Nash 2006-07-18 16:08 ` Paul R. Nash
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).