ldrex and strex instructions unsupported on (some) aarch32

[bremner]

What version of Racket are you using?

8.12 on

model name : ARMv7 Processor rev 2 (v7l)
Features        : half thumb fastmult vfp edsp thumbee vfpv3 tls idiva idivt vfpd32 lpae

This might be related to the fact that our only aarch32 machines are actually aarch64 machines
in emulation mode.

What program did you run?

./configure --enable-pb --enable-mach=tpb32l

or

./configure

What should have happened?

the build should complete

If you got an error message, please include it here.

/tmp/ccgkTVKT.s: Assembler messages:
/tmp/ccgkTVKT.s:1129: Error: selected processor does not support `ldrex r12,[r1]' in ARM mode
/tmp/ccgkTVKT.s:1132: Error: selected processor does not support `strex r7,r3,[r1]' in ARM mode
/tmp/ccgkTVKT.s:1187: Error: selected processor does not support `ldrex r12,[r2]' in ARM mode
/tmp/ccgkTVKT.s:1190: Error: selected processor does not support `strex r7,r1,[r2]' in ARM mode
/tmp/ccgkTVKT.s:1261: Error: selected processor does not support `ldrex r12,[r2]' in ARM mode
/tmp/ccgkTVKT.s:1264: Error: selected processor does not support `strex r7,r6,[r2]' in ARM mode
/tmp/ccgkTVKT.s:1353: Error: selected processor does not support `ldrex r12,[r2]' in ARM mode
/tmp/ccgkTVKT.s:1356: Error: selected processor does not support `strex r7,r6,[r2]' in ARM mode
/tmp/ccgkTVKT.s:3677: Error: selected processor does not support `ldrex r12,[r0]' in ARM mode
/tmp/ccgkTVKT.s:3680: Error: selected processor does not support `strex r7,r1,[r0]' in ARM mode
/tmp/ccgkTVKT.s:3759: Error: selected processor does not support `ldrex r12,[r0]' in ARM mode
/tmp/ccgkTVKT.s:3762: Error: selected processor does not support `strex r7,r2,[r0]' in ARM mode

Full log is at
https://buildd.debian.org/status/fetch.php?pkg=racket&arch=armel&ver=8.12%2Bdfsg1-6&stamp=1711006676&raw=0
Please include any other relevant details
e.g., the operating system used or how you are running the code.

[mflatt]

I think the solution is to change line 92 of "racket/src/ChezScheme/c/atomic.h" to

#elif defined(__arm__) && ((arm_isa_version >= 6) || (__ARM_ARCH >= 6))

With that change, I'm able to compile the Chez Scheme kernel using arm-linux-gnueabi-gcc.

[bremner]

Matthew Flatt ***@***.***> writes:

I think the solution is to change line 92 of "racket/src/ChezScheme/c/atomic.h" to ``` #elif defined(__arm__) && ((arm_isa_version >= 6) || (__ARM_ARCH >= 6)) ``` With that change, I'm able to compile the Chez Scheme kernel using `arm-linux-gnueabi-gcc`.

Interesting. 1) where/how is arm_isa_version defined? I could not find any reference to it other than in the racket source. 2) Do I need to regenerate something? I still get a failure in ``` gcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -DARMV6 -Ics/c/ChezScheme/tarm32le/boot/tarm32le -Ics/c/ChezScheme/tarm32le/c -I../src/ChezScheme/c/ -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/bremner/racket-8.12+dfsg1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -o cs/c/ChezScheme/tarm32le/c/gc-oce.o -c ../src/ChezScheme/c/gc-oce.c /tmp/ccvooWZO.s: Assembler messages: /tmp/ccvooWZO.s:56347: Error: selected processor does not support `ldrex r12,[r1]' in ARM mode /tmp/ccvooWZO.s:56349: Error: selected processor does not support `strex r7,r12,[r1]' in ARM mode ``` Naively it still looks like some of the scheme code (eg. src/ChezScheme/s/arm32.ss) unconditionally emits ldrex. Of course I don't really follow what code is run when.

[mflatt]

On arm_isa_version: I don't know. I copied it from the earlier check for ARMv7 in the same file. I must have gotten that earlier test from somewhere, maybe by checking predefined flags in some compiler's preprocessor, but I no longer remember.

The latest compilation failure you're showing is for tarm32le instead of tpb32l. Is that intentional, or did it happen despite configuring with --enable-mach=tpb32l? The tarm32le port requires at least ARMv6.

[bremner]

Matthew Flatt ***@***.***> writes:

The latest compilation failure you're showing is for `tarm32le` instead of `tpb32l`. Is that intentional, or did it happen despite configuring with `--enable-mach=tpb32l`? The `tarm32le` port requires at least ARMv6.

That was my mistake. I get farther with tpb32l, currently failing at ``` Converting cs/c/ChezScheme/tpb32l/boot/tpb32l/petite.boot to petite-pbchunk.boot and petite~a.c (time (pbchunk-convert-file in.boot ...)) 414 collections 311.190323520s elapsed cpu time, including 3.690057920s collecting 312.605668970s elapsed real time, including 3.711423917s collecting 2510011168 bytes allocated, including 2085038512 bytes reclaimed Converting cs/c/ChezScheme/tpb32l/boot/tpb32l/scheme.boot to scheme-pbchunk.boot and scheme~a.c (time (pbchunk-convert-file in.boot ...)) 294 collections 227.527878280s elapsed cpu time, including 2.576491520s collecting 228.529494168s elapsed real time, including 2.597056796s collecting 1823964072 bytes allocated, including 1927428736 bytes reclaimed Converting cs/c/racket.boot to racket-pbchunk.boot and racket~a.c out of memory failed in build-one in loop in module->hash make[1]: *** [Makefile:22: all] Error 1 make[1]: Leaving directory '/home/bremner/racket-8.12+dfsg1/build' dh_auto_build: error: cd build && make -j1 returned exit code 2 make: *** [debian/rules:15: binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 Command exited with non-zero status 2 1083.23user 14.64system 18:22.52elapsed 99%CPU (0avgtext+0avgdata 1583660maxresident)k 174472inputs+311512outputs (211major+1096159minor)pagefaults 0swaps ``` My current best guess is that it is hitting a 2G address limit, so the last, failing allocation is 500M. The behaviour is a bit surprising, it runs along for around 15 minutes with < 100M memory, then starts allocating swiftly. I'm not sure if this indicates a (gc?) bug, or if it just needs more than 2G of memory to build.

[mflatt]

It appears that the problem is keeping the generated C text all in memory before splitting it into multiple files. Using a temporary file reduces peak memory use by a factor of 10 or so, making the memory use on the order of 100MB instead of 1GB. I'll work on a Chez Scheme PR in that direction.

[bremner]

shuhung ***@***.***> writes:

Closed #4955 as completed.

Do you have a commit reference? I see plans / suggestions to fix, but nothing to cherry-pick cheers, d

[sorawee]

The fix is in the ChezScheme repo, which is linked above by the GitHub interface (cisco/ChezScheme#820). I think you need to open the GitHub webpage to be able to see it. That is, you won't see it when viewing from email.

For reference, the commit is then later included to the Racket repo as dbce392733569b6d910b66286c95d2fb2d6c91ff.

[shhyou]

shuhung @.***> writes:
Closed #4955 as completed.
Do you have a commit reference? I see plans / suggestions to fix, but nothing to cherry-pick cheers, d

From #4955:

• ChezScheme PR819 avoid wrong assembly code for threaded mode on ARMv5 and earlier cisco/ChezScheme#819
  (== cisco/ChezScheme@77494102f == a5e4574f)
• ChezScheme PR820 reduce memory use of pbchunk conversion cisco/ChezScheme#820
  (== cisco/ChezScheme@dbce3927 == 1a373f20)