This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [patch] relax16.c: Eliminate an assertion failure.
- To: Kazu Hirata <kazu at hxi dot com>
- Subject: Re: [patch] relax16.c: Eliminate an assertion failure.
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 12 Sep 2000 09:00:10 -0600
- cc: binutils at sources dot redhat dot com
- Reply-To: law at cygnus dot com
In message <200009120503.WAA12270@cygnus.com>you write:
> Hi,
>
> Attached is a patch to stop an abortion causesed by an assertion in
> bfd/reloc16.c.
>
> First, here is the way to cause this assertion failure.
>
> main1.c / main2.c (both the same contents)
>
> void
> test ()
> {
> main ();
> }
>
> int
> main ()
> {
> return 0;
> }
>
> Compile these with:
>
> h8300-hms-gcc -mh -Wl,--relax -Wall -O2 -fomit-frame-pointer -o bfdbug main
> 1.c main2.c
>
> Then I get:
>
> /usr/local/bin/h8300-hms-gcc -mh -Wl,--relax -Wall -o h8os.out main1.o main
> 2.o
> main2.o(.text+0x0):main2.c: multiple definition of `test'
> main1.o(.text+0x0):main1.c: first defined here
> main2.o(.text+0x6):main2.c: multiple definition of `main'
> main1.o(.text+0x6):main1.c: first defined here
> /usr/local/lib/gcc-lib/h8300-hms/2.96/../../../../h8300-hms/bin/ld: bfd ass
> ertion fail ../../src/bfd/reloc16.c:131
> collect2: ld returned 1 exit status
> make: *** [h8os.out] Error 1
>
> The problem is that a hash key entry for 'main' gets slipped _twice_
> as a result of relaxation even though both a symbol for 'main' in
> main.c and another one in main2.c get slipped only once each.
>
> I looked for something in the infrastructure that tells whether a
> given symbol is defined multiple times, but I could not find that. If
> such a thing were there, then I could at least conditionalize the
> assertion in question like:
>
> if (! multiple_definition)
> BFD_ASSERT (h->root.u.def.value == p->value);
>
> This is why I chose an easier way of simply deleting the assertion. I
> hate to remove an assertion that looks right, but I don't think any
> input, even erroneous like the one above, should hit that. (Another
> possible way of handling this is to prevent relaxation from happening
> by a global variable (or per-section variable?) that tells whether at
> least one symbol has been defined multiple times.)
I would prefer to avoid relaxing completely when we've had a fatal error
earlier during symbol processing.
Look hard enough and there should be some reasonable way to do that.
jeff