MIPS toolchain

[Robert N. M. Watson]

On 31 Jul 2011, at 12:22, Jayachandran C. wrote:

>> In fact, there are some toolchain bugs I'm running into that manifest only
>> in the SDE toolchain and not the FreeBSD toolchain.  (Mind you, Philip has
>> commented that in building Uboot for MIPS, he's found FreeBSD bugs that
>> don't appear in the SDE toolchain, so mileage varies).
> 
> Any idea what the bugs where? If there are fixes that can be
> backported without license issues, we take take a look at this.

I'm on travel currently, so don't have my notes on this with me, but as I recall they were primarily in some combination of as and ld. A few that come to mind off-hand:

(1) .noat appears not always to work: you sometimes get sequences that use $at without warnings from the assembler (this might be more SDE than the FreeBSD version of as, my recollection is a bit hazy -- I know the FreeBSD version appeared more correct in my experimentation than SDE in this regard)

(2) If you try to disable generation of divide by zero checks for ddiv (for example) by using --no-break and --no-trap, you end up with both break and trap instrumentation rather than neither (if I recall); later FSF versions appear to support a --argument of some sort that completely disables this, but both the FreeBSD and SDE versions seem not to include it

(3) ld's -o binary gives very mixed results; objcopy with a binary output type seems to consistently work

(4) I haven't yet spotted a way to prevent generation of madd/msub instructions when using a 64-bit MIPS architecture, although there were a moderate number of MIPS systems built that implement a 64-bit ISA without madd/msub (but I've not dug deeply yet, so have probably simply missed an arch option).

(5) I find it annoying, although perhaps it is a feature, that objdump -s generates MIPS register names without prefixed $ symbols, so can't be fed straight back into as :-). Changing the output syntax would probably confuse other stuff at this point, however.

I'll dig in a bit more when I get back to the office later this week and try to come up with a more reproducible description (and confirmation) of each. I'm not sure any of these is the source of the problems Philip has experienced with Uboot.

Robert