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

[Eric Raible]

Huh?

My email on 2/24 was definitely not intended to imply anything

about "old windows versions".  I was simply trying to make a suggestion

about how to locally configure tcc to avoid a reported compiler error.

In any case grischka responded 9 or so hours later to say

that the commit that caused that compiler error on windows

had been reverted.

- Eric

On Tue, Feb 27, 2024 at 10:51 PM Herman ten Brugge via Tinycc-devel <tinycc-devel@nongnu.org> wrote:

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