mips objcopy broken between 25/11 and 28/11

[Havard Eidnes <he%NetBSD.org@localhost>]

Hi,

it appears that some change between November 24 and November 28
has broken mips objcopy.  The symptom is that while the sbmips-el
and sbmips-eb builds succeed on November 24, but fail on November
28, but these are UPDATE builds, so what triggers it may lie
outside of this window.  The logs on releng.netbsd.org have been
rotated out, but recent builds show the same problem as mine.

The reason for failure is that the objcopy of boot.sym to boot
results in a humungous file with mostly NULs in it:

       link  boot/boot.sym
   text    data     bss     dec     hex filename
  44872     224    9384   54480    d4d0 boot.sym
creating boot from boot.sym...
-rw-r--r--  1 he  wheel  532737876 Nov 29 00:45 boot
checking sizes for boot/boot.sym... MAXIMUM LOAD SIZE EXCEEDED (532737876 > 
114688)

and failure is from the November 28 build, while earlier that
part of the build log looked like this:

       link  boot/boot.sym
   text    data     bss     dec     hex filename
  44856     224    9384   54464    d4c0 boot.sym
creating boot from boot.sym...
-rw-r--r--  1 he  wheel  45056 Nov 25 18:49 boot
checking sizes for boot/boot.sym... OK

An 'od -c' of the new huge "boot" file starts with:

0000000   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
3760037520   \0  \0  \0  \0 001     034   < 360   o 234   ' 001     035   <
3760037540  260 020 275   '  \0     035   <  \0   @ 275   ' 001      \b   <

i.e. there's boatload of more NULs at the start of the file.

However, even reverting the src/external/gpl3/bbinutils to the
state in early September (to 2.19.1) and rebuilding binutils
tools did *not* fix this problem.

Anyone have any clues as to what is going on here, and where the
root of the problem might lie?

The host is an amd64 machine running 5.0_STABLE.

Regards,

- Håvard