This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -gc-sections for elf32-dlx and possible buglette in elf32-target.h

On Thu, Jan 29, 2004 at 10:47:35AM -0000, Dave Korn wrote:
>   Now my first thought was to simply derive a hash table type from the elf
> hash table, add XXX_link_hash_newfunc and XXX_link_hash_table_create
> routines based on the bog-standard templates; in particular, the
> hash_table_create routine calls out to the _bfd_elf_link_hash_table_init
> routine, which should ensure the hash table type is correctly set up.  I
> hoped that this would cause all the elf-specific stuff to be pulled in
> correctly, and hoped that would convince the linker it was dealing with elf
> and make it gc the sections.
>   However, what it actually did was to start SEGVing.  I reverted the gc
> functions and #defs, leaving only the derived elf hash table type, but it
> still failed, so I knew it wasn't actually related to that.
>   On debugging, it emerged that the problem was occurring in
> _bfd_generic_link_output_symbols.  To be precise, in the loop following the
> comment:

> 	      /* Force all references to this symbol to point to
> 		 the same area in memory.  It is possible that
> 		 this routine will be called with a hash table
> 		 other than a generic hash table, so we double
> 		 check that.  */
> 	      if (info->hash->creator == input_bfd->xvec)
> 		{
>             if (h->sym != (asymbol *) NULL)
> 		    *sym_ptr = sym = h->sym;
> 		}
>   And this is where it dies, because it turns out that h->sym has the value
> 0xffffffff, which is not a legal pointer to a symbol!

What's your derived hash table entry look like?  If the standard hash
table entry is at the beginning, like every other target, this should
work fine.

>   So what I was hoping someone could explain to me is why this comparison
> between the info->hash->creator and the input_bfd->xvec should be a test for
> generic/non-generic hashtable, and whether my assumption that this clause
> should *not* be active in elf targets is correct.

No, your assumption is not correct, I think.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]