Re: [Tinycc-devel] problem on win64 with latest commit

[Herman ten Brugge]

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