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

Changed thread_create() to take the new thread entry point as parameter #30

Conversation

perlun
Copy link
Contributor

@perlun perlun commented May 19, 2015

This is here now to fix #21. The way we used to do things simply don't cut it with more recent versions of gcc. Hence, I changed thread_create to take two parameters instead:

  1. The name of the method that should be called as entry point for the new thread.
  2. An argument that will be passed to that method. (Can be NULL in cases where you don't need it)

Coincidentally, this is very similar to how pthread_create already does it. 😄

The servers have also been fixed to work now with this approach; at least the console and the vga servers seem to be operational. Hence, merging.

perlun added 30 commits May 10, 2015 14:44
Also cleaned up whitespace (system_calls.rb was using tabs instead of spaces in some places).
…-create-take-the-new-thread-entry-point-as-parameter
Background: I removed a return value in storm/include/storm/return_values.h. Then I started getting compilation errors like this:

main.c:258:13: error: duplicate case value
main.c:249:13: error: previously used here

The errors were rather strange since I hadn't done any modification to the main.c file! So I started looking at it. It turned out I was using completely bogus values here when checking the return values (C:s lack of "true" strict typing a la Java or C# comes to mind...). Because of this, and the fact that the enums had now changed values, I started getting these compile-time errors.

The first return value (STORM_RETURN_UNALIGNED_SECTION) was never ever returned from the called method (in elf.c). The second (STORM_RETURN_SUCCESS) just "happened" to be the same as RETURN_SUCCESS but I fixed it to be right now anyway.
This makes it easier when using system_thread_create(), since you almost always want to cast the parameter to this type anyway (to be able to use functions that receives a parameter other than void *).
perlun added 14 commits May 19, 2015 22:47
…elow.

The problem at hand here was, in the end, quite simple. We were trying to copy the stuff into the right location by creating a new pointer based on the ESP value minus the "stack base address". This was all in all correct, but the problem was that we were doing this while we had the *PL3* stack mapped. And that was the problem: we were using a memory address in the PL0 stack (since that's what ESP pointed to at the moment), so we were in essence writing to the wrong memory location...

Hard to find, but easy to fix once I managed to find it. Joy! :)
No need for an intermediate variable here.
@perlun
Copy link
Contributor Author

perlun commented May 19, 2015

(Sorry for the noisy diff. I should get better at cherrypicking out stuff which better belong elsewhere, or maybe even doing a separate branch/PR for such stuff. It just gets unreadable like this.)

perlun added a commit that referenced this pull request May 20, 2015
…e-the-new-thread-entry-point-as-parameter

Changed thread_create() to take the new thread entry point as parameter
@perlun perlun merged commit 2a8a94f into master May 20, 2015
@perlun perlun deleted the feature/make-thread-create-take-the-new-thread-entry-point-as-parameter branch May 20, 2015 05:22
perlun added a commit that referenced this pull request Sep 12, 2015
perlun added a commit that referenced this pull request Oct 8, 2018
)

It would previously use the PL0 stack for the newly created thread. This commit fixes this, so that the PL3 stack (which is much less limited in size) is used instead.

The use of the PL0 stack was a bug I introduced while fixing #21 via pull request #30, but since it was three years ago I can honestly not say with certainty whether this was "by design" or "by accident". Either way, doing this fix is much better than (ab)using the PL0 stack since the latter is limited in size to a single 4 KiB page => way too little for certain recursive programs and larger programs in general.

(This change was a drive-by change while I was researching the root cause for some issues mentioned in #120)
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.

[KERNEL BUG] update_data: tss_list == NULL (dispatch.c:94, process = console (1), thread = unnamed (3)
1 participant