🚀 go-pugleaf

I found some problems with ld 2.0 configured for "coff-m68k"


1. ld now appears to require LDEMULATION to be set to something. The list of
	acceptable values in the manual are not accepted any more: document
	needs updating to say that "sun3", "sun4" etc. are now accepted instead.

2. ld now issues a "warning, xxxxxx architecture of input file `yyyyy' incompatible
	with unknown output" when none of TARGET or OUTPUT_FORMAT and LDEMULATION
	is specified. 
	When configured for "coff-m68k", no mt file is found in the config directory
	and so the variable EMUL is not set in the Makefile. Thus, the default
	target ends up as "unknown" which means that ld must be fed with a 
	target by hand. 
	This is often the case when running ld in partial-link mode (ld -r) without 
	a script file. The trouble is, it is only a *warning*, not an *error* even 
	though garbage output file is produced (doesn't output any code, 
	although symbol table info is output correctly!). When running with
	ld -r, can this "warning" be turned off and the output file format
	default to the current input file architecture? This is how 1.94-beta
	behaved I think.

3. I copied config/m68k.mt config/m68k-coff.mt in order to get "sun3" as the
	default target (which *does* seem somewhat bogus, as the comment in that
	file says!).

4. ld -c xxx.sc for an "MRI-compatible" script file now doesn't accept so
	many of the script commands e.g. OUTPUT_FORMAT("coff-m68k") is now
	illegal, when 1.94-beta accepted it. Maybe this is now correct behaviour
	but I couldn't find any mention of this in ChangeLog. [ ld -

5. The Makefile.in for ld needs to be updated so that Makefile depends on
	the relevant config/mt-* files and so that ldmain.c depends on Makefile


Other than that, I think that the linker performs correctly for the following
scenarios:
		a.out -> coff     in partial-link mode (ld -r)
		coff -> coff	  in normal mode (produce absolute output).

Next, I will try it with a mixture of a.out and coff inputs, as well as with
a.out and coff archive libraries as input - these did not use to work with
binutils-beta-1.94.



Andrew Smith
Distributed Network Systems
SynOptics Communications Inc.




P.S. Is there any chance of a new GAS to take advantage of the new opcodes and
	use of MOTOROLA-style "move.b" opcodes in
	binutils-2.0/include/opcode/m68k.h ??? I put some patches up a few
	weeks ago but these will not work on this new style of m68k.h file.