Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimised watcom OS/2 builds crash on startup #55

Open
Tracked by #8
davidrg opened this issue Aug 22, 2022 · 0 comments · May be fixed by #340
Open
Tracked by #8

Optimised watcom OS/2 builds crash on startup #55

davidrg opened this issue Aug 22, 2022 · 0 comments · May be fixed by #340
Labels
bug OS/2 Kermit/2 only (or required for OS/2 support)
Milestone

Comments

@davidrg
Copy link
Owner

davidrg commented Aug 22, 2022

If you build for OS/2 using OpenWatcom 1.9 with optimizations turned on (-ox), C-Kermit crashes on startup with:

SYS1808:
The process has stopped. The software diagnostic
code (exception code) is 0001.

The point at which it crashes is ckomou.c:362

Turns out this is an issue with -s (remove stack overflow checks) specifically. MichalN says:

Seems the difference is that the code calls __TNK instead of __TNC in function prolog, but why that makes a difference I don't yet understand. The crashes are super weird because it's trap 1 i.e. debug breakpoint, but it seems to be the OS somehow generating that.

OK, now I understand at least most of it. The __TNC ("thunk and check" I guess) function checks the stack and grows it if necessary, then performs any necessary thunking for 16-bit code. The __TNK ("thunk") function only does the thunking. Which means it does not grow the stack.

I'm not sure if this is a defect in the runtime (__TNK function should grow the stack as well) or in the code generator plus runtime (there should be a separate thunk + grow function for this).

FYI, the thunking prolog is necessitated by calling 16-bit APIs and passing addresses of items on the stack to them. The data on the stack needs to be aligned so as to not cross 64K boundaries.

But at the same time the thread stack is not committed, uses the guard page mechanism, and needs to be grown page by page.

Solution -- don't use the -ox switch, use the individual -o? options instead. And don't use -s either.

And indeed it seems to build and run ok with -obmiler

@davidrg davidrg added the bug label Aug 22, 2022
@davidrg davidrg added this to the OS/2 milestone Aug 22, 2022
@davidrg davidrg added the OS/2 Kermit/2 only (or required for OS/2 support) label May 30, 2023
davidrg added a commit that referenced this issue Oct 8, 2024
Fixes #55 - turns out optimisation isn't broken in general (open watcom has some optimisations on by default), just the -s option (remove stack overflow checks) is problematic. Thanks to MichalN for figuring this out!
@davidrg davidrg linked a pull request Oct 8, 2024 that will close this issue
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug OS/2 Kermit/2 only (or required for OS/2 support)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant