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

[msokolov at ivan dot Harhan dot ORG (Michael Sokolov)]

John Marshall <john_w_marshall@palm.com> wrote:

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

Oh please, John, don't talk to me about binary compatibility. Anybody in the
world but you can teach me lessons on binary compatibility. Whose idea was it,
John, to define a new COFF reloc type out of the blue sky and use it in
official shipped libraries? When I asked you about that reloc type, you
answered that you picked it yourself without asking anyone and when/if you were
going to convert to mainline binutils, there would be no guarantee of any of it
staying.

For others on this list, John made his own version of binutils to target
PalmOS in the fashion he wanted (there are other ways, some of which had
already been deployed when he did it, which don't need this hack). He wanted to
access the data segment in the MacOS way, with A5 pointing at the end and using
negative offsets from it. For this he needed a special reloc. But not everyone
wants to use this method, and people who don't would much rather use the
mainline binutils without his hack. But he and his employer, who is the OS
vendor, cared only about their toolkit, and released a new version of the OS
SDK with COFF libraries using a reloc type of his own invention, not in any
ABIs, screwing people who want to use other ABI-compliant tools. The upshot of
this is that John is not the best teacher you should take binary compatibility
lessons from.

As for binary compatibility in this specific case of --embedded-relocs, John's
method has not been deployed in anything other than prc-tools for PalmOS (he
mentioned something about uClinux, but this is the first time I hear that: he
would have to elaborate if he wants this taken into consideration). There it is
used in the intermediate file between the linker and post-linker. The linker
and the post-linker are always invoked in tandem and the intermediate file
between them is not used for any interchange, so I believe this is very little
of an issue.

John is now saying that the format used by his patch is the established
standard in the field and any change would break it, but it's pathetic to
listen to him saying this given that he just changed it himself. As of January
2000 he was using a different format with the .reloc section having 2^1
alignment and 10-byte records instead of his current 12-byte ones, without the
padding field at the end. If indeed as he claims uClinux has been using his
format for 18 months, it must be the old one, and his patch would break it just
as mine would. He had his version of binutils publicly downloadable and he
actively endorsed its use (remember, John, your own words at PalmSource'99 in
October "do yourself a favor, use this version"?), and it used his old 10-byte
format. That was before I learned his true character, and at that time I
trusted him and used his version of binutils for my version of PalmOS prc-
tools. It is now out in the field using his old 10-byte format. I had no way of
knowing, as there were no indications from him, that he was planning to change
this format, so no one can blame me.

Anyway, this is for Nick to decide. I want *some* --embedded-relocs and will be
perfectly happy with any.

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

I have seen your code, but I didn't base mine on it. Instead, I based it on Ian
Lance Taylor's MIPS ECOFF code, changing only what absolutely had to be changed
because of differences between the COFF and ECOFF backends.

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

Let Nick decide on this.

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)