This is the mail archive of the
mailing list for the binutils project.
Re: mn10300 linker relaxations broken (patch)
- To: Alexandre Oliva <aoliva at redhat dot com>
- Subject: Re: mn10300 linker relaxations broken (patch)
- From: law at redhat dot com
- Date: Wed, 16 May 2001 11:05:15 -0700
- cc: binutils at sources dot redhat dot com, echristo at redhat dot com
- Reply-To: law at redhat dot com
In message <firstname.lastname@example.org>you write:
> There are very serious bugs with mn10300 linker relaxations. The most
> simple of them is that we sometimes relax negative values into
> zero-extended 16-bit operands.
Hmmm. I thought I was catching all this kind of stuff, but apparently
I missed one class of cases.
As for <0x7fff vs <= 0x7fff, probably a typo.
* elf-m10300.c (mn10300_elf_relax_section): Don't relax
negative 32-bit operands to 16 operands when the operand is
going to be zero-extended by the modified opcode.
Looks fine to me.
> The other, more serious problem, is that we don't adjust
> section+offset relocations, and all references to local labels are
> adjusted to section+offset by the assembler. (This is also a problem
> because references to labels become ambiguous, especially if the
> addends of the relocations are non-zero, but this is probably rare in
> comparison with direct references to labels).
Yes, relaxing depends on knowing the actual symbol and thus doens't like
sec + offset addressing modes. I thought we had the assembler never
generating sec + offset addressing modes for things which could potentially
[ We want to collapse to sec + offset and the like for stuff in the debug
sections to reduce the size of the symbol table. Otherwise we mostly
want to leave symbols unadjusted. ]
So, instead of checking if something is ST_CODE, you should check if it's
something in a loadable section. If it's in a loadable section, then do not
adjust it. If it is in an unloadable section (ie, debugging info), then
go ahead and adjust it.