This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


I wrote yesterday:

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

I did an investigation into uClinux (http://www.uclinux.org/), and here is what
I found. They indeed use a patched version of binutils with a patch by John
Marshall to implement --embedded-relocs. However, it is not his current one
with 12-byte records, nor is it his previous one with 10-byte ones. Instead,
it's yet another version: third! In this one the embedded reloc section is
called .dreloc instead of .reloc (and I was wondering all along why his
ChangeLog entries talk about .dreloc...), the records are 8 bytes long, have
the offset in the data section as a 16-bit value (OK for PalmOS where
everything is limited to 64 KB, but no good for m68k in general), and the COFF
external reloc types are used.

To summarize, John has made three different implementations of --embedded-
relocs, with three different and incompatible binary formats, all three of
which he either actively endorsed for general use or contributed to them being
deployed:

1. His original one with .dreloc, 8-byte records, and COFF external reloc
types. He can say that it's just an early version, but AFAICT, as that's what
is on their site, this is what uClinux uses currently.

2. The one with .reloc, 10-byte records, and his own reloc type "numbering"
(which is 1 for longword absolute and error for anything else). He had it in
his very raw and very alpha version of prc-tools, which he had on his WWW page
for all of late 1999. Despite it clearly being very raw and very alpha, he
actively endorsed it for general use by PalmOS developers at the PalmSource'99
conference. This is also what I ended up using in my version of PalmOS prc-
tools, which has been deployed as a release for 5 months now.

3. His last one with 12-byte records, which he posted here yesterday. This one
is used by the toolkit that his employer currently distributes and endorses.

So much for binary compatibility! Given all the above, I think it would be
pointless to consider any patches from John from the viewpoint of binary
compatibility.

Nick, have you reviewed my patch? Would you please respond to it? I'm not say
that my patch is the best possible, but if you tell me how to change it, I will
do it readily.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]