Re: [Tinycc-devel] Grischka last commit breaks some ports
On 12/19/20 10:40 AM, grischka wrote: Herman ten Brugge via Tinycc-devel wrote: On 12/18/20 2:45 PM, grischka wrote: Christian Jullien wrote: On OpenBSD: I noticed some tests were excluded but the reasons were say not really obvious: Test: 106_pthread... From it's name it's testing pthreads. OpenBSD appears to have pthreads. So what is the deal? I added a comment that pthread_condattr_setpshared does not exists. Better than nothing. Still someone might ask what the heck so interesting with pthread_condattr_whatnot is this trying to test at all? (You know that, and maybe I do, but...) Anyway, if printf had versyms then I'd just test that instead and while at it, rename to 106_versym. I guess it doesn't. I can rename the testcase if you want to. Test: 114_bound_signal... wait forever I think I mailed the reason before. The problem is in the libc implementation. - signals should be disabled during pthread_create - after a fork libc should init the internal i/o mutex for a client process. I fixed the pthread_create problem in bcheck.c but this does not work for bsd because of broken dlsym. I disabled the fork test on mac. All other libc do this correctly. Hm, on an alpine musl it does hang, sometimes. Sometimes it comes back after a few seconds. Sometimes almost instantly. Probably due to fork problem. This looks a lot like the mac problem. If you attach a debugger when the code hangs you probably see it waiting on on i/o mutex. There is also another problem. The dlltest does not work on arm(32 bits) because the jmp_buf has different size in tcc and gcc due to '__attribute__((__aligned__ (8)))' Only the "dlltest with PIC" links to a gcc file. But wrong size for TCCState is not good. See code below. tcc prints: 388 gcc prints: 392. If I move the jmpbuf field in the struct TCCState to the end the code works. Should we implement the aligned attribute in tcc or should we disable this test on arm32? We do have the aligned attribute in tcc and we tried to make it work. Also, your test does print 392 with tcc on a 32-bit windows: #define BF_DEBUG set field __val offset 0 size 128 align 4 struct size 128 align 4 set field __jmpbuf offset 0 size 256 align 8 set field __mask_was_saved offset 256 size 4 align 4 set field __saved_mask offset 260 size 128 align 4 struct size 392 align 8 Why it can be different on arm, hm..., maybe __attribute__ was defined to empty? The patch below fixes the problem. I will test on all targets before committing it. This is not the first time that I had a problem with __attribute__ Herman diff --git a/tcc.h b/tcc.h index a9a822e..373076d 100644 --- a/tcc.h +++ b/tcc.h @@ -28,6 +28,10 @@ #include #include #include +/* gnu headers use to #define __attribute__ to empty for non-gcc compilers */ +#ifdef __TINYC__ +# undef __attribute__ +#endif #include #include #include @@ -108,10 +112,6 @@ extern long double strtold (const char *__nptr, char **__endptr); # define PRINTF_LIKE(x,y) __attribute__ ((format (printf, (x), (y #endif -/* gnu headers use to #define __attribute__ to empty for non-gcc compilers */ -#ifdef __TINYC__ -# undef __attribute__ -#endif #ifdef _WIN32 # define IS_DIRSEP(c) (c == '/' || c == '\\') ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Grischka last commit breaks some ports
Herman ten Brugge via Tinycc-devel wrote:
On 12/18/20 2:45 PM, grischka wrote:
Christian Jullien wrote:
On OpenBSD:
I noticed some tests were excluded but the reasons were say
not really obvious:
Test: 106_pthread...
From it's name it's testing pthreads. OpenBSD appears to have
pthreads. So what is the deal?
I added a comment that pthread_condattr_setpshared does not exists.
Better than nothing. Still someone might ask what the heck so
interesting with pthread_condattr_whatnot is this trying to test
at all? (You know that, and maybe I do, but...)
Anyway, if printf had versyms then I'd just test that instead and
while at it, rename to 106_versym. I guess it doesn't.
Test: 114_bound_signal...
wait forever
I think I mailed the reason before.
The problem is in the libc implementation.
- signals should be disabled during pthread_create
- after a fork libc should init the internal i/o mutex for a client
process.
I fixed the pthread_create problem in bcheck.c but this does not work
for bsd because of broken dlsym.
I disabled the fork test on mac. All other libc do this correctly.
Hm, on an alpine musl it does hang, sometimes. Sometimes it comes
back after a few seconds. Sometimes almost instantly.
There is also another problem.
The dlltest does not work on arm(32 bits) because the jmp_buf has
different size in tcc and gcc due to '__attribute__((__aligned__ (8)))'
Only the "dlltest with PIC" links to a gcc file. But wrong size
for TCCState is not good.
See code below.
tcc prints: 388
gcc prints: 392.
If I move the jmpbuf field in the struct TCCState to the end the code
works.
Should we implement the aligned attribute in tcc or should we disable
this test on arm32?
We do have the aligned attribute in tcc and we tried to make it
work. Also, your test does print 392 with tcc on a 32-bit windows:
#define BF_DEBUG
set field __val offset 0 size 128 align 4
struct size 128 align 4
set field __jmpbuf offset 0 size 256 align 8
set field __mask_was_saved offset 256 size 4 align 4
set field __saved_mask offset 260 size 128 align 4
struct size 392 align 8
Why it can be different on arm, hm..., maybe __attribute__ was
defined to empty?
-- grischka
Herman
#include
typedef int __jmp_buf[64] __attribute__((__aligned__ (8)));
typedef struct
{
unsigned long int __val[(1024 / (8 * sizeof (unsigned long int)))];
} __sigset_t;
struct __jmp_buf_tag
{
__jmp_buf __jmpbuf;
int __mask_was_saved;
__sigset_t __saved_mask;
};
int
main(void)
{
printf ("%d\n", sizeof (struct __jmp_buf_tag));
return 0;
}
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Anyone else working with the RISC-V port?
I am interested in doing a project using TinyCC, a web-based IDE for the ESP32-C3, a wifi-enabled microcontroller. https://github.com/cnlohr/espwebc3/blob/main/README.md I spent a while trying to decipher riscv-gen, and it's actually not that bad. Very much inline with the cryptic TinyCC (ok, bit of a jab, but it's not that bad). It currently only supports RV64, vs the chip I'll be using supports RV32-IMC. Conveniently, most of the instructions implemented in riscv-gen are the 32-bit instructions, only a handful of RV64 instructions, which shouldn't be too difficult to avoid. Is anyone else working in this area? Has anyone expressed any possibility at adding a few more comments to the riscv-gen code? Are there any landmines I may run into? How eager would people be to add a -m32 flag for RISC-V? Charles ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
