MIPS ECOFF ld --embedded-relocs: looks like a bug

[Michael Sokolov]

John Marshall <john_w_marshall@palm.com> wrote:

> In fact I have already done this (for m68k COFF), over a year ago.  This
> code hasn't yet been contributed back to mainline binutils, but there is
> no real obstacle -- it is only because I have been very busy forever :-(,
> and contributing it can and should be pushed higher up my to do list.
>
> Michael is familiar with this code.  If there is some reason why it is
> not suitable for his needs, perhaps we could talk about that and extend
> it in a compatible way.
>
> (The code is at
>
>         http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/prc-tools/binutils-2.9.1.palmos.diff?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=prc-tools
>
> The relevant portion is _bfd_m68kcoff_create_embedded_relocs in the patch
> to coff-m68k.c, and m68kcoff.em.  Some of it would want tidying up a little
> (the declarations) before it would be suitable as a patch on this list.)

Do you have a copyright assignment on file with the FSF for your binutils
patches? I'm not allowed to bring your patch into consideration if you don't.

John, I need this feature in trunk binutils right now (for both COFF and ELF),
and if I am doing the work, make it acceptable to the binutils maintainers, and
have assigned the copyright to the FSF (snailed in my form over a month ago),
no one can deny it to me as a contributor. If you don't like my patch and want
yours instead, you'll have to compete in real time (I'm going to post my patch
later today). If you do, and I mean right now, as that's when I'm about to make
mine, Nick can choose one or the other. But if not, don't get upset if I make
mine, put it in the form acceptable to the maintainers, and get it checked in.
If my patch won't work for you, when you find time you can ask the maintainers
to change it to suit you. But I and the rest of binutils users, developers, and
maintainers can't wait indefinitely for you to get your act together and in the
meantime hold back my patch.

> > This caught my sight because I want to port this to m68k, where I will
> > definitely need to support both COFF and ELF and allow linking COFF objects
> > into ELF executables, together with ELF objects, with an ELF toolchain (and
> > maybe even vice-versa, although that is not important).
>
> Why is this so essential?

My primary toolchain will be ELF, and my users will normally compile their
sources into ELF objects and link them into ELF executables. However, I also
(unlike you) take object code compatibility very seriously, and I must be able
to swallow the existing COFF objects in the field. There already is PalmOS code
out there distributed in COFF objects without source. For an example, start
with yourself and your employer and the COFF libraries you ship in PalmOS SDK
3.5.

(A background note for people reading this: I and John make two different
competing environments for programming for the PalmOS handheld embedded system
with GNU tools, very much like Cygwin and Mingw32 for Win32. John's environment
has been taken over by the OS vendor whom he works for now, but since I still
find my environment vastly superior to theirs, have a responsibility to my
users, and dislike any vendor-controlled development environments outright, I
continue maintaining my competing environment. I also have great difficulties
dealing with John personally.)

> I had got the impression that this may well be
> broken in lots of ways.  See, for example,
>
>         http://sourceware.cygnus.com/ml/binutils/1999-q2/msg00305.html
>         http://sourceware.cygnus.com/ml/binutils/2000-04/msg00500.html

What I see there is that some people don't care about this feature and want to
break or drop it, but in both cases Ian Lance Taylor, who is the binutils
developer I admire most and whom I'm very sorry to see step down as the
maintainer, said that this was intended, should work, and is relied upon by
people, especially those forced to use proprietary software in object form. I
will need this to work for m68k COFF and ELF, and if it doesn't, I'll fix it.

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