This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [cross-binutils-2.15.91.0.2] assertion fail linker.c:619
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: Pawe?? Sikora <pluto at pld-linux dot org>, binutils at sources dot redhat dot com
- Date: Wed, 18 Aug 2004 11:27:25 +0930
- Subject: Re: [cross-binutils-2.15.91.0.2] assertion fail linker.c:619
- References: <200408171142.21199.pluto@pld-linux.org> <20040817221610.GA15555@lucon.org>
On Tue, Aug 17, 2004 at 03:16:10PM -0700, H. J. Lu wrote:
> The problem is bfd_link_add_undef assumes h->und_next == NULL. But it
> may not be true in all cases, depending on how lucky/unlucky you are.
> This patch seems to fix the testcase. But I am not sure if it is 100%
> correct.
I don't think it's right. und_next should be NULL at the tail of the
list. You need to fix some place where an undefined symbol finds
a definition.
Hmm, it so happens that the ELF linker doesn't traverse the list (except
for ppc64 with a recent patch of mine), so und_next is effectively just
a flag. Neither are entries removed from the list (except again for
ppc64). So I'm not certain what we should do here. Obviously, I need
to ensure that the ppc64 list traversal doesn't fall off the end of the
list, or loop..
> --- linker.c.undef 2004-08-13 08:00:10.000000000 -0700
> +++ linker.c 2004-08-17 15:14:00.595475841 -0700
> @@ -616,7 +616,7 @@ void
> bfd_link_add_undef (struct bfd_link_hash_table *table,
> struct bfd_link_hash_entry *h)
> {
> - BFD_ASSERT (h->und_next == NULL);
> + BFD_ASSERT (h->und_next == NULL || h->und_next == table->undefs_tail);
> if (table->undefs_tail != NULL)
> table->undefs_tail->und_next = h;
> if (table->undefs == NULL)
--
Alan Modra
IBM OzLabs - Linux Technology Centre