Re: mn10300 linker relaxations broken (patch)

[law at redhat dot com]

  In message <orlmo0aaov.fsf@guarana.lsd.ic.unicamp.br>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
be relaxed.

[ 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.

jeff