|
From: | Christian Jullien |
Subject: | Re: [Tinycc-devel] Progress on the Thumb2 generator, testing |
Date: | Sun, 5 Apr 2020 18:14:51 +0200 |
Hi Erlend, Congrat for your progress. Few hints to help you debug this. If it stops at the first char, it is “probably” because wchar_t has an incorrect size (like 2 vs. 4) compared to the string encoded with L”…”. It stops with the NUL wchar_t. // this file contains BMP chars encoded in UTF-8 #include <stdio.h> #include <wchar.h> int main() { wchar_t s[] = L"hello$$你好¢¢世界€€world"; wchar_t *p; { unsigned char* byte = (unsigned char*)&s[0]; int i; for (i = 0; i < sizeof(s); ++i) { printf("p=%p => %02X\n", byte, *byte); ++byte; } } printf("sizeof(wchar_t) %d\n", sizeof(wchar_t)); printf("sizeof(s) %d\n", sizeof(wchar_t)); for (p = s; *p; p++) { printf("p=%p => %04X\n", p, (unsigned) *p); } return 0; } Rpi4 gives: $ tcc foo.c -o foo && ./foo | more p=0xbeba3508 => 68 p=0xbeba3509 => 00 p=0xbeba350a => 00 p=0xbeba350b => 00 p=0xbeba350c => 65 p=0xbeba350d => 00 p=0xbeba350e => 00 p=0xbeba350f => 00 p=0xbeba3510 => 6C p=0xbeba3511 => 00 p=0xbeba3512 => 00 p=0xbeba3513 => 00 p=0xbeba3514 => 6C p=0xbeba3515 => 00 p=0xbeba3516 => 00 p=0xbeba3517 => 00 p=0xbeba3518 => 6F p=0xbeba3519 => 00 p=0xbeba351a => 00 p=0xbeba351b => 00 p=0xbeba351c => 24 p=0xbeba351d => 00 p=0xbeba351e => 00 p=0xbeba351f => 00 p=0xbeba3520 => 24 p=0xbeba3521 => 00 p=0xbeba3522 => 00 p=0xbeba3523 => 00 p=0xbeba3524 => 60 p=0xbeba3525 => 4F p=0xbeba3526 => 00 p=0xbeba3527 => 00 p=0xbeba3528 => 7D p=0xbeba3529 => 59 p=0xbeba352a => 00 p=0xbeba352b => 00 p=0xbeba352c => A2 p=0xbeba352d => 00 p=0xbeba352e => 00 p=0xbeba352f => 00 p=0xbeba3530 => A2 p=0xbeba3531 => 00 p=0xbeba3532 => 00 p=0xbeba3533 => 00 p=0xbeba3534 => 16 p=0xbeba3535 => 4E p=0xbeba3536 => 00 p=0xbeba3537 => 00 p=0xbeba3538 => 4C p=0xbeba3539 => 75 p=0xbeba353a => 00 p=0xbeba353b => 00 p=0xbeba353c => AC p=0xbeba353d => 20 p=0xbeba353e => 00 p=0xbeba353f => 00 p=0xbeba3540 => AC p=0xbeba3541 => 20 p=0xbeba3542 => 00 p=0xbeba3543 => 00 p=0xbeba3544 => 77 p=0xbeba3545 => 00 p=0xbeba3546 => 00 p=0xbeba3547 => 00 p=0xbeba3548 => 6F p=0xbeba3549 => 00 p=0xbeba354a => 00 p=0xbeba354b => 00 p=0xbeba354c => 72 p=0xbeba354d => 00 p=0xbeba354e => 00 p=0xbeba354f => 00 p=0xbeba3550 => 6C p=0xbeba3551 => 00 p=0xbeba3552 => 00 p=0xbeba3553 => 00 p=0xbeba3554 => 64 p=0xbeba3555 => 00 p=0xbeba3556 => 00 p=0xbeba3557 => 00 p=0xbeba3558 => 00 p=0xbeba3559 => 00 p=0xbeba355a => 00 p=0xbeba355b => 00 sizeof(wchar_t) 4 sizeof(s) 4 p=0xbeba3508 => 0068 p=0xbeba350c => 0065 p=0xbeba3510 => 006C p=0xbeba3514 => 006C p=0xbeba3518 => 006F p=0xbeba351c => 0024 p=0xbeba3520 => 0024 p=0xbeba3524 => 4F60 p=0xbeba3528 => 597D p=0xbeba352c => 00A2 p=0xbeba3530 => 00A2 p=0xbeba3534 => 4E16 p=0xbeba3538 => 754C p=0xbeba353c => 20AC p=0xbeba3540 => 20AC p=0xbeba3544 => 0077 p=0xbeba3548 => 006F p=0xbeba354c => 0072 p=0xbeba3550 => 006C p=0xbeba3554 => 0064 From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=address@hidden] On Behalf Of Erlend Sveen Hello again. I have been making some good progress on the Thumb2 code generator. I'm now on the latest version of TCC, and have almost all of the tests in the tests2 directory working (excluding those using floats and/or inline asm). There is one test in particular that I'm struggling with, 97_utf8_string.c. TCC Seems to think that the string is an integer or something, printing these warnings: tinycc/tests/tests2/97_utf8_string_literal.c:7: warning: assignment makes integer from pointer without a cast tinycc/tests/tests2/97_utf8_string_literal.c:7: warning: cast between pointer and integer of different size Compiling with the regular ARM cross compiler makes the same instruction sequence. If I run the program it only prints the first character. Does anyone have an idea of what is happening here? --- Next question is about testing in general. From what I can tell, it seems like running the tests only run on the regular x86 version and does not check anything with the cross compilers. Is this correct? If so, how are the cross compilers tested? It looks like it only checks that it will compile ex3.c, and that compiling and running running all the tests requires a target system to do it on (as in, there is no emulation, check for generation of undefined instructions/malformed files or other things). Reason I'm asking is that I'm uncertain about how testing of arm-thumb-tcc fits into all of this. In order to do my testing, I've made a separate testing harness. A shell script compiles a list of the relevant tests with TCC and link them against the C library that I've written. Another script then transfers all the executables to the target filesystem. I wrote a simple test runner that uses posix_spawn to run all the tests on the microcontroller and compares the output. The OS supports most of the things needed by the tests and does full memory protection, which makes testing fairly straight forward. Even the grep test works (although it must be run manually). However the OS is fairly niche (I've written it), and runs on a microcontroller so the hardware is fairly specific. Any thoughts? The testing program could be made to work on Linux with little modification, so someone might find a use of it, but I'd like to hear some opinions on how to do this. Other than this I think it is getting ready for review soon. Hopefully someone will have time for a quick look. I'll put up a temporary repo somewhere when the time comes. Current testing hardware is: * stm32f767igt6 with Cortex-M7 @ 216 MHz * 8MiB of additional external RAM. * 8MiB of external NOR Flash for root filesystem. + A bunch of other peripherals If I'm not mistaken the Thumb2 generator should work with any Cortex-M3, M4 and M7 microcontrollers but I've not tested those CPUs yet (I have some lying around). Regards, Erlend Sveen |
[Prev in Thread] | Current Thread | [Next in Thread] |