On 2016/03/26 20:13, Karel Gardas wrote: > have you tried to bootstrap your own gcc with recent binutils? i.e. > --with-as=<your new binutils as>... On the other hand you may also > give a try to LLVM/clang from ports and see if they support your > required features...
OpenBSD binutils is modified for things like W^X. As far as i386 and amd64 go it's probably a more useful approach to write support for the additional opcodes, see the most recent couple of commits in src/gnu/usr.bin/binutils-2.17 for clues about how to do this. For some other arch (ARM in particular) support in binutils-2.17 is a bit of a stumbling point...not sure quite what to do there. Alternatively yes do try LLVM/Clang as that has its own assembler. > > /tmp//ccF2Aqg7.s: Assembler messages: > > /tmp//ccF2Aqg7.s:1668791: Error: no such instruction: `popcntl > > -4(%rbp),%eax' > > /tmp//ccF2Aqg7.s:1669741: Error: no such instruction: `popcntq > > -8(%rbp),%rax' > > > > -> Are there plans to support more modern CPU-extensions and is there a list > > somewhere of which extensions are supported and which ones aren't? I guess > > they could be useful for other low-level stuff like encryption, as well.. There's no single list of all extensions supported. You can find the additions to binutils-2.17 by reading commit log, for example XSAVE, SMAP, RDRAND/RDSEED and the virtualization instructions were added. 2.17 already supported AESNI. > > --> If not, should the gcc-port be adapted to not offer those extensions > > that aren't supported? Yes.
