Hello, Trying to build nettle 2.7 for an arm10 system of mine using its (old) toolchain fails with assembler errors.
arm-linux-gcc -Os -I[...] -I. -DHAVE_CONFIG_H -g -O2 -ggdb3 -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT aes-decrypt-internal.o -MD -MP -MF aes-decrypt-internal.o.d -fpic -c aes-decrypt-internal.s aes-decrypt-internal.s: Assembler messages: aes-decrypt-internal.s:81: Error: bad instruction `push {r4,r5,r6,r7,r8,r10,r11,lr}' aes-decrypt-internal.s:87: Error: register or shift expression expected -- `orr r4,r8,lsl#8' aes-decrypt-internal.s:89: Error: register or shift expression expected -- `orr r4,r8,lsl#16' aes-decrypt-internal.s:91: Error: register or shift expression expected -- `orr r4,r8,lsl#24' aes-decrypt-internal.s:93: Error: bad arguments to instruction -- `eor r4,r8' [...] make[2]: *** [aes-decrypt-internal.o] Error 1
$ arm-linux-as -v GNU assembler version 2.16.1 (arm-linux-uclibc) using BFD version 2.16.1
Trying with the latest buildroot another error is issued:
arm-buildroot-linux-uclibcgnueabi-as -v GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
arm-buildroot-linux-uclibcgnueabi-gcc -I. -DHAVE_CONFIG_H -pipe -Os -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT aes-encrypt-internal.o -MD -MP -MF aes-encrypt-internal.o.d -fpic -c aes-encrypt-internal.s aes-encrypt-internal.s: Assembler messages: aes-encrypt-internal.s:140: Error: selected processor does not support ARM mode `uxtb r8,r2' aes-encrypt-internal.s:142: Error: selected processor does not support ARM mode `uxtb r8,r3' aes-encrypt-internal.s:144: Error: selected processor does not support ARM mode `uxtb r8,r12' aes-encrypt-internal.s:146: Error: selected processor does not support ARM mode `uxtb r8,r14'
Any ideas?
regards, Nikos
On Wed, 8 May 2013, Nikos Mavrogiannopoulos wrote:
Trying with the latest buildroot another error is issued:
arm-buildroot-linux-uclibcgnueabi-as -v GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
arm-buildroot-linux-uclibcgnueabi-gcc -I. -DHAVE_CONFIG_H -pipe -Os -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT aes-encrypt-internal.o -MD -MP -MF aes-encrypt-internal.o.d -fpic -c aes-encrypt-internal.s aes-encrypt-internal.s: Assembler messages: aes-encrypt-internal.s:140: Error: selected processor does not support ARM mode `uxtb r8,r2' aes-encrypt-internal.s:142: Error: selected processor does not support ARM mode `uxtb r8,r3' aes-encrypt-internal.s:144: Error: selected processor does not support ARM mode `uxtb r8,r12' aes-encrypt-internal.s:146: Error: selected processor does not support ARM mode `uxtb r8,r14'
The uxtb instruction requires ARMv6, while an ARM10 is ARMv5, afaik.
So the functions using uxtb should only be enabled if the target is >= ARMv6, not arm in general. (The check can probably be done by testing to assemble such instructions, just as the check for neon does.)
// Martin
Martin Storsjö martin@martin.st writes:
The uxtb instruction requires ARMv6, while an ARM10 is ARMv5, afaik.
I see.
So the functions using uxtb should only be enabled if the target is >= ARMv6, not arm in general. (The check can probably be done by testing to assemble such instructions, just as the check for neon does.)
So the aes functions could be moved to an arm/v6 subdirectory (the uxtb occurs in aes.m4, included in the aes-*.asm).
What alternative are there to uxtb? The easiest alternative is to have a series of rotates and ands.
But if we sacrifice a register to hold the byte mask 0xff, uxtb can be replaced by an and with rotate.
This even has the advantage that we can offset the rotate by two bits, and avoid shifting the index when it is used for the table lookup.
So instead of, e.g,
uxtb T0, X, ror #8 ldr [TABLE, T0, lsl #2]
put the value 0x3fc in MASK, and do
and T0, MASK, X, ror#6 ldr [TABLE, T0]
Eliminating a shift/rotate operation might even make the code faster.
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
So instead of, e.g,
uxtb T0, X, ror #8 ldr [TABLE, T0, lsl #2]
put the value 0x3fc in MASK, and do
and T0, MASK, X, ror#6 ldr [TABLE, T0]
Eliminating a shift/rotate operation might even make the code faster.
I have tried this now. I get same speed if I do this trick to the main round transformations. But uxtb is also used in the final round, and I'm having some difficulty replacing that with and without making it slower.
Timing on the A9 appears to be very sensitive, adding a single instruction, even a nop, can slow it down a lot. And for the final round, we do substitutions via the sbox table, and hence need the mask 0xff rather than 0x3fc, and the single instruction to set that up seems remarkably expensive.
So I think we may need separate versions.
Regards, /Niels
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Trying to build nettle 2.7 for an arm10 system of mine using its (old) toolchain fails with assembler errors.
arm-linux-gcc -Os -I[...] -I. -DHAVE_CONFIG_H -g -O2 -ggdb3 -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT aes-decrypt-internal.o -MD -MP -MF aes-decrypt-internal.o.d -fpic -c aes-decrypt-internal.s aes-decrypt-internal.s: Assembler messages: aes-decrypt-internal.s:81: Error: bad instruction `push {r4,r5,r6,r7,r8,r10,r11,lr}' aes-decrypt-internal.s:87: Error: register or shift expression expected -- `orr r4,r8,lsl#8' aes-decrypt-internal.s:89: Error: register or shift expression expected -- `orr r4,r8,lsl#16' aes-decrypt-internal.s:91: Error: register or shift expression expected -- `orr r4,r8,lsl#24' aes-decrypt-internal.s:93: Error: bad arguments to instruction -- `eor r4,r8' [...] make[2]: *** [aes-decrypt-internal.o] Error 1
I recently got a similar bugreport from a user with an arm system running freebsd with an ancient GNU as. I think it would make sense to use more traditional ARM asm syntax. Things I'm aware of:
1. Always use 3-operand form instructions, i.e.,
add r1, r1, r2
rather then
add r1, r2
2. Write shift and rotate instructions as mov with a shift/rotate operand.
3. Add explicit ia/db suffixes on push, pop, ldm, stm.
4. Some file uses "unified" assembler syntax. Revert to traditional arm syntax (unless we have a good reason to support compiling to thumb instructions? I don't really understand pros and cons there).
I don't have time to test that right now, but patches are welcome. Is it a common enough problem that it motivates a bug-fix release?
Regards, /Niels
On Wed, 8 May 2013, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Trying to build nettle 2.7 for an arm10 system of mine using its (old) toolchain fails with assembler errors.
arm-linux-gcc -Os -I[...] -I. -DHAVE_CONFIG_H -g -O2 -ggdb3 -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT aes-decrypt-internal.o -MD -MP -MF aes-decrypt-internal.o.d -fpic -c aes-decrypt-internal.s aes-decrypt-internal.s: Assembler messages: aes-decrypt-internal.s:81: Error: bad instruction `push {r4,r5,r6,r7,r8,r10,r11,lr}' aes-decrypt-internal.s:87: Error: register or shift expression expected -- `orr r4,r8,lsl#8' aes-decrypt-internal.s:89: Error: register or shift expression expected -- `orr r4,r8,lsl#16' aes-decrypt-internal.s:91: Error: register or shift expression expected -- `orr r4,r8,lsl#24' aes-decrypt-internal.s:93: Error: bad arguments to instruction -- `eor r4,r8' [...] make[2]: *** [aes-decrypt-internal.o] Error 1
I recently got a similar bugreport from a user with an arm system running freebsd with an ancient GNU as. I think it would make sense to use more traditional ARM asm syntax. Things I'm aware of:
Always use 3-operand form instructions, i.e.,
add r1, r1, r2
rather then
add r1, r2
- Write shift and rotate instructions as mov with a shift/rotate
operand.
Add explicit ia/db suffixes on push, pop, ldm, stm.
Some file uses "unified" assembler syntax. Revert to traditional arm
syntax (unless we have a good reason to support compiling to thumb instructions? I don't really understand pros and cons there).
I wouldn't suggest moving away from the unified syntax - being able to build for both thumb and arm from the same source is useful. Normally it's sufficient to support only arm mode, but there are certain cases where you want/need to build in thumb mode. One of them is the fact that windows 8 on arm (WinRT and Windows Phone 8) only supports thumb mode.
If the instructions can be written more elaborately to allow older tools to assemble them, without making the code itself worse, it's probably a good tradeoff.
// Martin
Martin Storsjö martin@martin.st writes:
I wouldn't suggest moving away from the unified syntax - being able to build for both thumb and arm from the same source is useful.
Ok, if that is useful, I guess we should move in the opposite direction and use it for *all* arm assembly files. But I'm worrying that the same old assemblers which barf on
orr r4,r8,lsl#8
may also barf on the itee instruction which is required for conditional execution in unified syntax. Except possibly conditional branches, I don't remember. Could of course use some configure/m4 magic to get around that, if we think it's worth the effort.
Regards, /Niels
On Wed, 8 May 2013, Niels Möller wrote:
Martin Storsjö martin@martin.st writes:
I wouldn't suggest moving away from the unified syntax - being able to build for both thumb and arm from the same source is useful.
Ok, if that is useful, I guess we should move in the opposite direction and use it for *all* arm assembly files. But I'm worrying that the same old assemblers which barf on
orr r4,r8,lsl#8
may also barf on the itee instruction which is required for conditional execution in unified syntax. Except possibly conditional branches, I don't remember. Could of course use some configure/m4 magic to get around that, if we think it's worth the effort.
Hmm, I don't have much experience with the older binutils so I don't know for sure if they've got a problem with the it instructions or not. In general this might be a good direction, but there's probably not much need to actually make it all the way and finish it unless someone steps up to do it (having an actual need at the time), as long as we aren't moving in the opposite direction.
// Martin
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Trying with the latest buildroot another error is issued:
arm-buildroot-linux-uclibcgnueabi-as -v GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
arm-buildroot-linux-uclibcgnueabi-gcc -I. -DHAVE_CONFIG_H -pipe -Os -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT aes-encrypt-internal.o -MD -MP -MF aes-encrypt-internal.o.d -fpic -c aes-encrypt-internal.s aes-encrypt-internal.s: Assembler messages: aes-encrypt-internal.s:140: Error: selected processor does not support ARM mode `uxtb r8,r2' aes-encrypt-internal.s:142: Error: selected processor does not support ARM mode `uxtb r8,r3' aes-encrypt-internal.s:144: Error: selected processor does not support ARM mode `uxtb r8,r12' aes-encrypt-internal.s:146: Error: selected processor does not support ARM mode `uxtb r8,r14'
I've checked in new AES code for pre-v6 processors. Can you test if it works now? Haven't yet tried to address the other issue, with supporting older assemblers.
Regards, /Niels
On 05/16/2013 04:57 PM, Niels Möller wrote:
arm-buildroot-linux-uclibcgnueabi-as -v GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1
arm-buildroot-linux-uclibcgnueabi-gcc -I. -DHAVE_CONFIG_H -pipe -Os -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT aes-encrypt-internal.o -MD -MP -MF aes-encrypt-internal.o.d -fpic -c aes-encrypt-internal.s aes-encrypt-internal.s: Assembler messages: aes-encrypt-internal.s:140: Error: selected processor does not support ARM mode `uxtb r8,r2' aes-encrypt-internal.s:142: Error: selected processor does not support ARM mode `uxtb r8,r3' aes-encrypt-internal.s:144: Error: selected processor does not support ARM mode `uxtb r8,r12' aes-encrypt-internal.s:146: Error: selected processor does not support ARM mode `uxtb r8,r14'
I've checked in new AES code for pre-v6 processors. Can you test if it works now? Haven't yet tried to address the other issue, with supporting older assemblers.
I now get errors in sha1 and sha256 code. I used make -i and no other code seems to fail.
/home/nmav/cvs/buildroot/output/host/usr/bin/ccache /home/nmav/cvs/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -I. -DHAVE_CONFIG_H -pipe -Os -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT sha1-compress.o -MD -MP -MF sha1-compress.o.d -fpic -c sha1-compress.s sha1-compress.s: Assembler messages: sha1-compress.s:79: Error: selected processor does not support ARM mode `uadd8 r7,r7,r12' sha1-compress.s:86: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:89: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:103: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:106: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:120: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:123: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:137: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:140: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:154: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:157: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:172: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:175: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:189: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:192: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:206: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:209: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:223: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:226: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:240: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:243: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:258: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:261: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:275: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:278: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:292: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:295: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:309: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:312: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:326: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:329: Error: selected processor does not support ARM mode `rev r12,r12' sha1-compress.s:344: Error: selected processor does not support ARM mode `sel r12,r10,r7' sha1-compress.s:347: Error: selected processor does not support ARM mode `rev r12,r12'
/home/nmav/cvs/buildroot/output/host/usr/bin/ccache /home/nmav/cvs/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -I. -DHAVE_CONFIG_H -pipe -Os -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT sha256-compress.o -MD -MP -MF sha256-compress.o.d -fpic -c sha256-compress.s sha256-compress.s: Assembler messages: sha256-compress.s:93: Error: selected processor does not support ARM mode `uadd8 r12,r12,r4' sha256-compress.s:99: Error: selected processor does not support ARM mode `sel r3,r3,r4' sha256-compress.s:101: Error: selected processor does not support ARM mode `rev r3,r3' sha256-compress.s:102: Error: selected processor does not support ARM mode `sel r4,r4,r5' sha256-compress.s:104: Error: selected processor does not support ARM mode `rev r4,r4' sha256-compress.s:105: Error: selected processor does not support ARM mode `sel r5,r5,r6' sha256-compress.s:107: Error: selected processor does not support ARM mode `rev r5,r5' sha256-compress.s:108: Error: selected processor does not support ARM mode `sel r6,r6,r7' sha256-compress.s:110: Error: selected processor does not support ARM mode `rev r6,r6' make[1]: [sha256-compress.o] Error 1 (ignored) rm -f libnettle.a
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
I now get errors in sha1 and sha256 code. I used make -i and no other code seems to fail.
I see. Does it work if you move the offending source files in arm/ to the subdirectory arm/v6? In the build tree, you need either make distclean, or remove corresponding symlinks manually.
The instructions which fail are used for reading the possibly unaliged input area, and it seems some different tricks will be needed for pre-v6 ARM. (I haven't yet checked the ARM manual, so I'm not 100% sure in which arch version they were introduced, but I guess they're also ARMv6)
Regards, /Niels
On 05/19/2013 08:12 AM, Niels Möller wrote:
I now get errors in sha1 and sha256 code. I used make -i and no other code seems to fail.
I see. Does it work if you move the offending source files in arm/ to the subdirectory arm/v6? In the build tree, you need either make distclean, or remove corresponding symlinks manually.
Yes, this is what I eventually did (i deleted those files).
regards, Nikos
nisse@lysator.liu.se (Niels Möller) writes:
I see. Does it work if you move the offending source files in arm/ to the subdirectory arm/v6? In the build tree, you need either make distclean, or remove corresponding symlinks manually.
I just pushed a branch "nettle-2.7-fixes" to the public repo, intended to also fix the pre-v6 ARM problems.
Regards, /Niels
On 05/21/2013 04:25 PM, Niels Möller wrote:
nisse@lysator.liu.se (Niels Möller) writes:
I see. Does it work if you move the offending source files in arm/ to the subdirectory arm/v6? In the build tree, you need either make distclean, or remove corresponding symlinks manually.
I just pushed a branch "nettle-2.7-fixes" to the public repo, intended to also fix the pre-v6 ARM problems.
I tried to build this branch using mingw32 and I got linking issues with libnettle.a and libhogweed.a (in that system I get libnettle.dll.a.
By fixing the makefiles to link with the LIBNETTLE_FILE and LIBHOGWEED_FILE fixes the issue in mingw, but creates a problem on linux where libnettle.so is built but LIBNETTLE_FILE is libnettle.so.4.7.
Any ideas?
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
I tried to build this branch using mingw32 and I got linking issues with libnettle.a and libhogweed.a (in that system I get libnettle.dll.a.
Is that a general problem, or just with this branch? There shouldn't be any windows-related changes there.
I just tested
$ ~/hack/nettle-stable/configure --host=i586-mingw32msvc $ make check
and that works fine for me (EMULATOR=wine). I guess you're doing something differently, maybe native compilation, or w*ndows-8 on arm, or something?
By fixing the makefiles to link with the LIBNETTLE_FILE and LIBHOGWEED_FILE fixes the issue in mingw, but creates a problem on linux where libnettle.so is built but LIBNETTLE_FILE is libnettle.so.4.7.
If the currrent setup doesn't work, you need to change the setup of LIBNETTLE_FILE (or invent some new variables if required) and set it all up inside the
case "$host_os"
in configure.ac. And then substitute those values at the right place in Makefile.in. I don't remember exactly how it's supposed to work, but maybe the _FORLINK variables are the ones you need.
Regards, /Niels
On 05/21/2013 10:35 PM, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
I tried to build this branch using mingw32 and I got linking issues with libnettle.a and libhogweed.a (in that system I get libnettle.dll.a.
Is that a general problem, or just with this branch? There shouldn't be any windows-related changes there. I just tested
$ ~/hack/nettle-stable/configure --host=i586-mingw32msvc $ make check and that works fine for me (EMULATOR=wine). I guess you're doing something differently, maybe native compilation, or w*ndows-8 on arm, or something?
I was using the additional flags: --enable-shared --disable-static
It seems the issue was due to --disable-static with which built cannot complete (the Makefile.ins assume that the static libraries are always there).
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
It seems the issue was due to --disable-static with which built cannot complete (the Makefile.ins assume that the static libraries are always there).
I see, I haven't tested --disable-static very much, and definitely not in this setup. Then I should be able to reproduce the problem.
About the pre-v6 ARM problems, are those solved now?
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Martin Storsjö -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se