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

os/StartProcess #4377

Open
wants to merge 13 commits into
base: dev
Choose a base branch
from
Open

os/StartProcess #4377

wants to merge 13 commits into from

Conversation

leongross
Copy link
Contributor

This is a rework of #4323 (based on that branch) to move the Execve and Fork wrappers to the os package to circumvent the goroot overrides.

@leongross leongross force-pushed the os/StartProcessOs branch 6 times, most recently from 43fcf8f to 8cce6c2 Compare August 2, 2024 12:06
Copy link
Member

@aykevl aykevl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick initial (incomplete) review

src/os/osexec.go Outdated Show resolved Hide resolved
src/os/osexec.go Outdated Show resolved Hide resolved
src/os/exec_other.go Show resolved Hide resolved
src/os/exec_linux.go Outdated Show resolved Hide resolved
@leongross
Copy link
Contributor Author

leongross commented Aug 5, 2024

main_test.go:394: /home/runner/work/tinygo/tinygo/src/os/osexec.go:14:23: undefined: syscall.Syscall

ci fails with undefined syscall.Syscall. I thought since it is just a package the compiler would pick that up when building it. @aykevl

EDIT: it looks like this is only happening on architectures that the createRawSyscall function does not target, which makes sense, namely EmulatedCortexM3 : cortex-m-qemu and EmulatedRISCV : riscv-qemu. Anyways, this should not happen.
https://github.com/tinygo-org/tinygo/blob/dev/main_test.go#L522

Anyhow the smoke tests fail without any further information of what went wrong on linux, windows and mac. the smoke test cannot be removed, it is not clear though why it wasn't build in the first place

rm: cannot remove 'smoke.test': No such file or directory

@leongross leongross marked this pull request as ready for review August 6, 2024 12:39
@leongross
Copy link
Contributor Author

leongross commented Aug 8, 2024

Not sure if something like #4398 would fix this? @aykevl

@aykevl
Copy link
Member

aykevl commented Aug 8, 2024

Not sure if something like #4398 would fix this? @aykevl

No, that's the wrong approach. If syscall.Syscall fails on baremetal systems, then the solution is not to implement these syscalls (because they're baremetal, so there is no OS to call into), but rather to figure out why these calls are made.

src/os/osexec.go Outdated Show resolved Hide resolved
@leongross leongross requested a review from aykevl August 8, 2024 14:57
@leongross leongross force-pushed the os/StartProcessOs branch 3 times, most recently from e369ae7 to bf011fe Compare August 9, 2024 10:19
@leongross leongross force-pushed the os/StartProcessOs branch 3 times, most recently from 246b809 to bbf1159 Compare August 22, 2024 09:40
Signed-off-by: leongross <leon.gross@9elements.com>
src/os/tempfile.go Outdated Show resolved Hide resolved
@leongross
Copy link
Contributor Author

@deadprogram @dgryski @aykevl build and tests finally succeed, would appreciate another review.

@leongross leongross changed the title [rework] os/SartProcess os/SartProcess Aug 28, 2024
@leongross
Copy link
Contributor Author

@aykevl @deadprogram @dgryski would someone mind reviewing?

src/os/osexec.go Outdated Show resolved Hide resolved
@deadprogram deadprogram changed the title os/SartProcess os/StartProcess Sep 6, 2024
Copy link
Member

@aykevl aykevl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • There is some commented out code, that looks like testing code. IMHO it should either be used, or removed (it doesn't really add any value in documentation).
  • You make a few changes to the syscall package, but why? All actual operating systems (Linux, macOS, Windows) use the default syscall package. If you need any changes to the syscall package, that probably indicates that it is called from somewhere (for example, baremetal) and you need to adjust build tags.

src/os/exec.go Outdated Show resolved Hide resolved
src/syscall/syscall_unix.go Outdated Show resolved Hide resolved
src/os/tempfile.go Outdated Show resolved Hide resolved
Comment on lines +23 to +26
const (
SYS_FORK = 57
SYS_EXECVE = 59
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These can be removed, because every actual operating system we have (Linux, MacOS, Windows) doesn't use the TinyGo syscall package.
(If removing these leads to compilation errors, you're probably using them from something that's not an operating system and probably need to adjust build tags at the call site).

src/os/osexec.go Outdated
Comment on lines 12 to 14
// ret := libc_fork()
// ret, _, _ := syscall.Syscall(syscall.SYS_FORK, 0, 0, 0)
ret, _, _ := syscall.Syscall(57, 0, 0, 0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't use magic numbers. Use syscall.SYS_FORK instead, for example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the explicit syscall number and found out, that in the CI the definition for SYS_FORK cannot be found. Grepping through the source tree I found out, that there is no definition for this, only the local go installation provides this, e.g. via src/syscall/zsysnum_linux_amd64.go. What confused me is that the CI should have picked this up but did not. On my local machine, this works perfectly fine.

src/os/exec_other.go Outdated Show resolved Hide resolved
src/os/osexec.go Outdated

// fail := libc_execve(&argv0[0], &argv1[0], &env1[0])
// fail, _, _ := syscall.Syscall(syscall.SYS_EXECVE, uintptr(unsafe.Pointer(&argv0[0])), uintptr(unsafe.Pointer(&argv1[0])), uintptr(unsafe.Pointer(&env1[0])))
fail, _, _ := syscall.Syscall(59, uintptr(unsafe.Pointer(&argv0[0])), uintptr(unsafe.Pointer(&argv1[0])), uintptr(unsafe.Pointer(&env1[0])))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't use magic numbers. It looks like you can use syscall.Exec instead.

Comment on lines +43 to +44
// TODO: parse the syscall return codes
return errors.New("execve failed")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you implement this TODO?
(If you use syscall.Exec you already have an error value to return!)

Comment on lines +42 to +46
// * No setting of Process Attributes
// * Ignoring Ctty
// * No ForkLocking (might be introduced by #4273)
// * No parent-child communication via pipes (TODO)
// * No waiting for crashes child processes to prohibit zombie process accumulation / Wait status checking (TODO)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to check for these cases, and if users use any of these to return an error instead of continuing and not doing what the user expected?
For example, if Stdin is set, it should either implement that feature or return an error.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds like a reasonable thing to do. I will evaluate this and see how/if this is possible.

Comment on lines +50 to +52
func (p *ProcessState) Exited() bool {
return false // TODO
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's... a little ugly.
Is there any way we can track whether the process is still running?

remove old comments, replace explicit syscall numbers with named
variants, undo tempfile seed generation, remove old // +build tags,
improve StartProcess documentation.

Signed-off-by: leongross <leon.gross@9elements.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants