Re: GNU binutils 2.17.50 retirement planning
On Mon, 26 Nov 2018 at 10:52, Ed Maste wrote:
>
> The most significant issue is
> sys/crypto/skein/amd64/skein_block_asm.s, and it makes extensive use
> of GNU macro extensions. I have looked at nasm and yasm but believe
> the macro extension support in those is less developed than in Clang's
> IAS.
>
> There are a number of files in stand/ tagged with CLANG_NO_IAS, in
> gptzfsboot, cdboot, zfsboot, boot2, and pxeldr. These could likely be
> removed now (they were added because Clang IAS did not support .codeNN
> long ago), but they need to be tested first because the generated
> output is slightly different.
In addition to those, on amd64 there are two other sets of .s files
currently assembled by GNU as:
* i386 boot components (stand/i386/{btx,kgzldr,libi386,mbr,pmbr})
* amd64 linuxulator (sys/amd64/linux{,32})
On i386 there are some others:
* kernel (sys/i386/i386)
* i386 linuxulator (sys/i386/linux)
* dtrace tests (cddl/contrib/opensolaris/cmd/dtrace/test/tst/i386)
* vm86 test tool (tools/test/vm86)
(Other architectures not yet investigated.)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GNU binutils 2.17.50 retirement planning
On Sat, 24 Nov 2018 at 17:24, Charlie Li wrote: > > some Makefile logic in stand/i386/btx specify a > hard-coded /usr/bin/as without bootstrapped binutils, necessitating a > symlink. Which logic specifically? I can't seem to find it. > If it is true that the only assembly files that clang IAS cannot > assemble are for amd64 and i386, has there been any research into nasm > and yasm at least? nasm is specified as a build dependency in certain > multimedia/ ports, and yasm in gecko@, for amd64 and i386 assembly code. > Both are licensed under some BSD licence variant. The most significant issue is sys/crypto/skein/amd64/skein_block_asm.s, and it makes extensive use of GNU macro extensions. I have looked at nasm and yasm but believe the macro extension support in those is less developed than in Clang's IAS. There are a number of files in stand/ tagged with CLANG_NO_IAS, in gptzfsboot, cdboot, zfsboot, boot2, and pxeldr. These could likely be removed now (they were added because Clang IAS did not support .codeNN long ago), but they need to be tested first because the generated output is slightly different. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GNU binutils 2.17.50 retirement planning
On Sun, 25 Nov 2018 at 07:52, David Chisnall wrote: > > We probably need to kill ld.bfd before 12.0. It predates ifunc and so > interprets anything with an ifunc as requiring a copy relocation. I posted https://reviews.freebsd.org/D18340 to stop installing ld.bfd when LLD_IS_LD is enabled. This will have the effect of removing ld.bfd on amd64 (where ifuncs are in use) as well as other architectures which do not yet use ifuncs, but this seems like a reasonable step in the process of removing these obsolete tools. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GNU binutils 2.17.50 retirement planning
On 23 Nov 2018, at 16:23, Ed Maste wrote: > > For some time we have been incrementally working to retire the use of > obsolete GNU Binutils 2.17.50 tools. At present we still install three > binutils by default: > > as > ld.bfd > objdump We probably need to kill ld.bfd before 12.0. It predates ifunc and so interprets anything with an ifunc as requiring a copy relocation. This means that if you use it to link against any shared library (like, say, libc.so.7 in FreeBSD 12.0) that uses ifuncs then it will insert a relocation so that the ifunc resolver (which contains PC-relative addresses of other functions) will be copied into the main binary. This then causes your program to crash the first time anything calls memcpy, in a very difficult-to-debug way (it jumps into a random bit of your main binary, runs for a bit, and then dies). David ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GNU binutils 2.17.50 retirement planning
On 23/11/2018 11:23, Ed Maste wrote: > Retiring GNU as requires further investigation and effort as we have > some assembly files (for amd64 at least) which cannot be assembled by > Clang's integrated assembler. If Clang gains support for the required > functionality we'll switch to using IAS for all assembly files, and if > not we could rewrite the few assembly files to work with IAS. > I've been using the port binutils as for quite some time on amd64 (with WITHOUT_BINUTILS and WITHOUT_BINUTILS_BOOTSTRAP) with success by specifying XAS, although some Makefile logic in stand/i386/btx specify a hard-coded /usr/bin/as without bootstrapped binutils, necessitating a symlink. I temporarily re-enabled binutils bootstrap in trying to figure out the r339898 regression with retpoline, so things may have changed in light of r340681. If it is true that the only assembly files that clang IAS cannot assemble are for amd64 and i386, has there been any research into nasm and yasm at least? nasm is specified as a build dependency in certain multimedia/ ports, and yasm in gecko@, for amd64 and i386 assembly code. Both are licensed under some BSD licence variant. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
GNU binutils 2.17.50 retirement planning
For some time we have been incrementally working to retire the use of obsolete GNU Binutils 2.17.50 tools. At present we still install three binutils by default: as ld.bfd objdump The intent is to retire all of these by FreeBSD 13. Depending on tool and architecture we will just remove it, migrate to LLVM tools, or rely on external toolchain components. Retiring GNU as requires further investigation and effort as we have some assembly files (for amd64 at least) which cannot be assembled by Clang's integrated assembler. If Clang gains support for the required functionality we'll switch to using IAS for all assembly files, and if not we could rewrite the few assembly files to work with IAS. ld.bfd is installed, but is not the default linker (/usr/bin/ld) on amd64, arm64 and arm, and soon i386 as well. We can just stop installing it at the appropriate time. For objdump I have proposed installing LLVM's llvm-obdump as objdump, in review D18307. It does not support all of the options that GNU objdump does, but is usable for many common operations. In addition, non-obsolete GNU objdump is available in the binutils port or package. Please try out llvm-objdump and see if it supports the options you need/use, and add a note in PR 229046 if not. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
