On 2/27/24 19:51, grischka wrote:
On 26.02.2024 19:55, Herman ten Brugge via Tinycc-devel wrote:
I commited a change to lib/runmain.c to silence a warning from gcc.
After that testcase 112 did not work any more on 64 bits windows
(tested with wine).
I can fix this with fix1 (see below) or fix2 (see below).
I do not know enough about windows to make the correct fix.
Both fix1/fix2 look not correct to me.
Hi Herman,
well, first we'd need to know what problem we want to fix. Maybe
the problem is not in tinycc at all.
Also, the obvious to avoid that gcc warning IMO would be using:
__attribute__((noreturn)) void __rt_exit(rt_frame *, int);
Also, while at it:
# ifdef _WIN32
# define CONFIG_RUNMEM_RO 0
# else
# define CONFIG_RUNMEM_RO 1
# endif
would suggest a special case needed for windows. However that is not
the case. Whereas according to your comment, the exception is APPLE
actually. So we'd better say #ifdef __APPLE__ or just use '1' for all
and leave a comment that it's needed for APPLE.
Although tests on github actions did not show such problem, at least
not on macos-11. Note that CONFIG_RUNMEM_RO was first introduced with
.rodata sections in commit 72f1dea5372ed551d203311e4f2ab769a54de9bd
from 2021-02, and it seems that tcc already did work on MacOS even
before that commit. If those previous commits still work then the
problem now might be elsewhere.
Anyway, we cannot disable the runtime-function-unwind table because
without it longjmp() would crash on (a real) _WIN64.
Also obviously, if __rt_exit doesn't return, then any code after it
cannot have any effect:
__rt_exit(&f, code);
+ abort (); // avoid noreturn warning
I'd assume something weird going on with set/longjmp of WINE and/or
the mingw-gcc that you use. In any case it is important that
setjmp/longjmp/jmp_buf implementations do match each other.
Which is why I made it so that tcc_setjmp records the longjmp
function pointer too because otherwise it could end up using the
longjmp from libtcc.dll/so and the setjmp from the application
that links to it, with possibly different concepts each. (Not
sure if/where it really can happen though).
There is probably a bug in the wine stack unwinding code.
The __attribute__((noreturn)) looks like the correct fix. I will apply it.
I made the change to CONFIG_RUNMEM_RO because it was set to 1
before and that worked on all targets. I saw a mail from Eric Raible
on 25 Feb 2024 that it should be set to 0 for old window versions.
This is why I made the change to only effect windows.
On most targets setting it to 0 or 1 did work. (Not tested on all)
I use an apple machine from the gcc compile farm.
Darwin cfarm104.cfarm.net 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug
22 20:20:05 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T8101 arm64
I did not check why it failed but with CONFIG_RUNMEM_RO=0 it reported:
mprotect failed (did you mean to configure --with-selinux?)
Using --with-selinux on apple works but looked strange.
I also noticed that maybe --with-selinux is not needed any more
with the recent changes. I removed it on all my test targets.
Herman
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
