This is the mail archive of the
mailing list for the binutils project.
Re: -gc-sections for elf32-dlx and possible buglette in elf32-target.h
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Dave Korn <dk at artimi dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Thu, 29 Jan 2004 09:51:55 -0500
- Subject: Re: -gc-sections for elf32-dlx and possible buglette in elf32-target.h
- References: <NUTMEG72FHi2p3ecfCB00000059@NUTMEG.CAM.ARTIMI.COM>
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
> /* 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
> 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.
MontaVista Software Debian GNU/Linux Developer