mn10300 relaxing bug

[Nick Clifton]

Hi DJ,

   [Sorry - hit send too soon].

> Fun question here: The mn10300 uses function symbols to keep track of
> which relaxations are possible (i.e. it's a flags field in the symtab
> hash).  However, when relaxing C++ thunks there are cases where you
> have two symbols referring to the start of one function.  In this
> case, sometimes one symbol indicates that the call->calls relaxation
> can happen, but the other one says it can't.  So, the relaxation
> happens and half the calls work and the other crash.
> 
> How are we supposed to deal with this?

Use something other than function symbols to keep track of this 
information ?  eg a separate section with a map of flags for entry point 
addresses ?

> FYI I've come up with this patch so far, which looks for multiple
> local symbols with the same address, so it can merge the flags.

This also seems to be a reasonable solution.

> Passes ld's make-check plus the application which showed the problem.

For something like this, I would be more happy with it not introducing 
any regressions into the G++ testsuite for the mn10300...

> +	qsort (entries, static_count, sizeof(entries[0]), sort_by_value);
> +
> +	for (i=0; i<static_count-1; i++)
> +	  if (entries[i]->value && entries[i]->value == entries[i+1]->value)
> +	    {
> +	      int v = entries[i]->flags;
> +	      int j;
> +	      for (j=i+1; j<static_count && entries[j]->value == entries[i]->value; j++)
> +		v |= entries[j]->flags;
> +	      for (j=i; j<static_count && entries[j]->value == entries[i]->value; j++)
> +		entries[j]->flags = v;
> +	      i = j-1;
> +	    }
> +      }

Hmm - is this going to make the mn10300 port very slow at linking ?


Anyway the patch looks OK to me, so if you are happy with it please feel 
free to apply it.

Cheers
   Nick