Re: PATCH to bfd: embedded relocs for m68k COFF as discussed with Ian

[John Marshall <john_w_marshall at palm dot com>]

> I will also make my post-linker tools grok the relocs
> in the format generated here, and John can easily do the same with his.

This would, of course, create a minor binary compatibility problem for
several thousand people.  It's only a small one, but if the alternatives
are otherwise functionally equivalent I think it should count.

> 2000-06-08  Michael Sokolov  <msokolov@ivan.Harhan.ORG>
> 
> 	* coff-m68k.c (bfd_m68k_coff_create_embedded_relocs): New function.

Given that this code is almost identical to code that I researched
and wrote 18 months ago and which Michael has seen, I don't think the
attribution is quite right.  More importantly, it seems to me that not
disclosing this risks exposing the FSF to the theoretical legal attacks
mentioned in http://www.gnu.org/prep/standards_4.html#SEC4 .

> +       /* We can only relocate absolute longword relocs at run time.  */
> +       if (irel->r_type != R_RELLONG)
> + 	{
> + 	  *errmsg = _("unsupported reloc type");

Given that we don't know what various systems using this stuff might
want to do with different relocations, it doesn't seem right to just
carry over the restrictions that were appropriate for the particular
MIPS MagicLink system.

A similar comment applies to check_sections() in the ld part.
For example, some system might want to have several data sections, all
with runtime relocation needs.  Indeed, the output format in this patch
can't represent that.

    John