Update binutils for OpenSSL asm support

[shigeki]

In the discussion of nodejs/node#19944, we have to update binutils version in CI according to the requirements of OpenSSL-1.1.1 asm support if you make opt-in for `openssl_no_asm' option.

The new requirements are

### OpenSSL asm support

OpenSSL requires the following asssembler version for use of asm
support.

* gas (GNU assembler) version 2.26 or higher
* xcode version 5.0 or higher
* llvm version 3.3 or higher
* nasm version 2.11.8 or higher in Windows

Otherwise, build with `--openssl-no-asm` in configure.

*Note:* This requirements come from the forthcoming OpenSSL-1.1.1. See
 https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_ia32cap.html for
 details.

At the current ,the following CI would be failed due to the older assembler version. Can we make update them?

debian8-64: 'gas_version': '2.25',
debian8-x86: 'gas_version': '2.25',
ubuntu1404-32: 'gas_version': '2.24',
ubuntu1404-64: 'gas_version': '2.24',
ppcle-ubuntu1404: 'gas_version': '2.24',
smartos15-64: 'gas_version': '2.25',
rhel72-s390x: 'gas_version': '2.25',
cc-armv6:'gas_version': '2.25',
cc-armv7:'gas_version': '2.25',

aix61-ppc64: defined no_asm? (Not sure it has assembler)

[rvagg]

OK .. this is going to be a problem .. the cc-armv6 and cc-armv7 machines are doing cross compiling and 2.25 is the highest we have access to for that, at least from the raspbian tools distribution. We may need to go sniffing out a new toolchain for this. I don't know enough about this to know whether we can just drop in a new custom version of as or whether we have to get the whole toolchain. Linaro is probably the place to go for a new one I suppose. /cc @joaocgreis

debian8 and ubuntu1404 might be tricky. I'll have to go hunting down a solution for that.

Unfortunately we're also using debian8 currently to build armv6 and armv7 binaries as well, they are not cross-compiled over there so that's another complication.

smartos15-64 we can retire.

ppcle-ubuntu1404 and rhel72-s390x are in @mhdawson and @gibfahn's hands.

[rvagg]

After spending way too many hours yesterday trying too begin shaving this yak, I'm coming to the conclusion that this busts our minimum compiler requirements and potentially even pushes out our minimum supported linux versions for some of our binaries.

@shigeki do you know the scale of the performance cost that no-asm imposes on binaries?

@jasnell IMO this puts 10.0.0 release timeline at risk, there's too many infra things to figure out here and limited brain cells and hours available to sort it out

[bnoordhuis]

scale of the performance cost that no-asm imposes on binaries?

Orders of magnitude for things like AES on architectures with hardware support.

[rvagg]

@bnoordhuis I suppose ARMv6 and ARMv7 wouldn't have much hardware crypto support so would it make much difference for those?

[shigeki]

IIRC, AES-NI is supported aarch64.

But actually GNU as version requirements mainly need for x86-64 not for ARMv6/v7 but it gets too complex to have both architecture and assembler version dependencies.

Another remedy is to have asm_obsolete as we did in openssl-1.0.2 of https://github.com/nodejs/node/tree/v8.x-staging/deps/openssl/asm_obsolete for older assembler.
I'm going to work on it.

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.