port-sparc64/51925: The sparc/sparc64 ports consider EM_SPARC32PLUS equivalent to EM_SPARCV9

[guillem%debian.org@localhost]

>Number:         51925
>Category:       port-sparc64
>Synopsis:       The sparc/sparc64 ports consider EM_SPARC32PLUS equivalent to EM_SPARCV9
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-sparc64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 29 21:15:00 +0000 2017
>Originator:     Guillem Jover
>Release:        HEAD
>Organization:
Debian
>Environment:
>Description:
While implementing ABI matching based on the ELF header data in dpkg-shlibdeps, and checking how various implementations handled mapping the alternative or legacy ELF machine IDs. I noticed that the NetBSD sparc and sparc64 ports consider the EM_SPARC32PLUS to be equivalent to EM_SPARCV9 when the object is ELFCLASS64.

This seems wrong and inconsistent with any of the other implementations I've checked, including Linux, FreeBSD, OpenBSD, GNU binutils and LLVM.

It also does not seem like anything will emit that kind of ELF object? So it would seem safe to drop the equivalence?

The dpkg code, for which I've had to add the special casing is:

  <https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Shlibs/Objdump.pm#n216>

The NetBSD code involved is:

 <http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/sparc/include/elf_machdep.h?rev=1.6.122.1&content-type=text/x-cvsweb-markup>
 <http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/sparc64/include/elf_machdep.h?rev=1.11&content-type=text/x-cvsweb-markup>

in the MACHDEP_ID_CASES macros. In any case I thought I'd drop a bug in case you agree, and I can eventually remove that special case. :)
>How-To-Repeat:

>Fix: