glibc - clone_fallback compile issue

[qianxichen233]

This PR is splited from PR #164

This PR focuses on spliting out the fix for __clone_internal_fallback function.

This could probably better be an issue rather a PR.

There is a weird bug on __clone_internal_fallback: when compiling some large applications, the generated wasm binary code at __clone_internal_fallback is incorrect and made the entire wasm binary unable to run. I currently havn't figured out if this is a bug from clang or it's due to something else. This is a very brutal temporary solution that directly removed the body of this function, this workaround at least made the compiled binary be able to run.

[rennergade]

Lets leave this PR up for now and open up an issue.

At the very least if we do merge we need to add comments saying that we removed this and why.

[rennergade]

I looked further into this and I think its fine to remove the function if its doing weird things when compiling, its only there to support systems that don't do clone3 and we do.

It's only called once in spawni if clone3 returns ENOSYS, we should probably add some sort of panic there if we got into a situation where it was somehow called. We definitely need to add comments here explaining as well.

[qianxichen233]

I looked further into this and I think its fine to remove the function if its doing weird things when compiling, its only there to support systems that don't do clone3 and we do.

It's only called once in spawni if clone3 returns ENOSYS, we should probably add some sort of panic there if we got into a situation where it was somehow called. We definitely need to add comments here explaining as well.

How are we supposed to trigger a panic here? One option is to use glibc’s assert, and another is to use our own debug_panic. I’d prefer debug_panic, but that raises another question: how do we propagate a debug_panic back to the host? One approach would be to define a new wasm import specifically, but I am not very sure if we all agree on this approach

[rennergade]

I looked further into this and I think its fine to remove the function if its doing weird things when compiling, its only there to support systems that don't do clone3 and we do.
It's only called once in spawni if clone3 returns ENOSYS, we should probably add some sort of panic there if we got into a situation where it was somehow called. We definitely need to add comments here explaining as well.

How are we supposed to trigger a panic here? One option is to use glibc’s assert, and another is to use our own debug_panic. I’d prefer debug_panic, but that raises another question: how do we propagate a debug_panic back to the host? One approach would be to define a new wasm import specifically, but I am not very sure if we all agree on this approach

Importing debug panic probably makes sense

[Yaxuan-w]

Could we call make_legacy_syscall/make_3i_syscall and panic in 3i?

[JustinCappos]

Any undefined syscall should debug_panic. Maybe have a macro that adds a large number like 1000 to the call number and panics. Then you can do DEBUG_PANIC(OPEN_SYSCALL, 189124, 2, 3, 4, 5) and have the output say: "DEBUG_PANIC: 3i got unknown system call with arguments 1002, 189124, 2, 3, 4, 5". I'm open to other suggestions, but every line where you do a debug panic should have an easy way to find that LOC again, ideally by grepping. I used 189124 (a random value I typed) for that purpose.

…

On Tue, Dec 2, 2025 at 7:08 AM Alice Wen ***@***.***> wrote: *Yaxuan-w* left a comment (Lind-Project/lind-wasm#359) <#359 (comment)> Could we call make_legacy_syscall/make_3i_syscall and panic in 3i? — Reply to this email directly, view it on GitHub <#359 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD7EUQGUDEG5ZH7STR337V6NJAVCNFSM6AAAAACE6XJWZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMBRG4YTAMRUGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rennergade]

@Yaxuan-w @JustinCappos going to do quick recap here in case the discussion above is confusing.

• On systems that don't support clone3 (we do support it) there is a fallback function that calls to clone()
• this fallback function is causing compilation (not runtime) errors. We support clone3 so we're going to remove it and comment.
• the scenario where it's called should never happen (since we support clone3) but I want to panic there if it does get hit somehow.
• we haven't added a syscall here, so we don't trampoline into trusted to call lind_debug_panic even though that seems like an appropriate thing to call.
• Qianxi suggested adding a hook to call lind_debug_panic from trusted code such as libc in situations where changes were made but its not a syscall addition

[JustinCappos]

@Yaxuan-w @JustinCappos going to do quick recap here in case the discussion above is confusing.

• On systems that don't support clone3 (we do support it) there is a fallback function that calls to clone()
• this fallback function is causing compilation (not runtime) errors. We support clone3 so we're going to remove it and comment.
• the scenario where it's called should never happen (since we support clone3) but I want to panic there if it does get hit somehow.
• we haven't added a syscall here, so we don't trampoline into trusted to call lind_debug_panic even though that seems like an appropriate thing to call.
• Qianxi suggested adding a hook to call lind_debug_panic from trusted code such as libc in situations where changes were made but its not a syscall addition

Thanks for the clear summary! Please make sure the comments are also clear about this.