| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
Previously, if the create() call would incorrectly kill the pfs process,
the test would still succeed as exit codes were not verified, and there
were no other way of identifying successful completion.
|
| |
|
|
|
|
|
|
| |
GCC 10 uses -fno-common by default, which makes multiple definitions of the same symbol in multiple
object files an error. This was used in the userspace test library, and broke with GCC10. Therefore,
the relevant symbol is now marked as "weak" to solve the issue and to clarify the intent.
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |
|
|
| |
Signed-off-by: Filip Strömbäck <fstromback@gmail.com>
|
| |
|
|
| |
Signed-off-by: Filip Strömbäck <fstromback@gmail.com>
|
| |
|
|
| |
Signed-off-by: Filip Strömbäck <fstromback@gmail.com>
|
| | |
|
| |
|
|
| |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |
|
|
| |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |
|
|
| |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |
|
|
|
|
|
|
|
|
|
| |
It seems that the BSS segment got larger than one page for some reason,
which caused the test to be useless as the boundary to nonmapped memory
were not located where the test thought. Now, it uses some linker script
magic to define the symbol _bss_end, the address of which is after the
end of the bss segment. This seems to be a fool-proof way of detecting
where the real boundary to unmapped memory is.
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |
|
|
| |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |
|
|
| |
space for 3 parameters instead of 4
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test userprog/exec-missing verifies that exec() returns -1 when
starting a process for which the binary is not found. Since the failure
of load() is discovered after a new process has been created, the output
'no-such-file: exit(-1)' will be visible in the output. The problem is
that we do not know when this happens with respect to the thread calling
exec(). Due to how the tests are designed, the time when 'no-such-file'
terminates is important. Some of the cases were listed as acceptable
outputs, but I found some acceptable outputs missing from there, namely
if 'no-such-file' for some reason takes quite some time terminating, or
even terminates after the 'exec-missing' process exits. As there is no
synchronization between these processes (nor can it be), we do not know
which one terminates first.
Effectively, I added the following possible outputs to the test, as I
find them reasonable outcomes of a correct implementation (in very
unfortunate circumstances, or when printing a lot in process_cleanup):
(exec-missing) begin
load: no-such-file: open failed
(exec-missing) exec("no-such-file"): -1
(exec-missing) end
no-such-file: exit(-1)
exec-missing: exit(0)
(exec-missing) begin
load: no-such-file: open failed
(exec-missing) exec("no-such-file"): -1
(exec-missing) end
exec-missing: exit(0)
no-such-file: exit(-1)
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |/ |
|
| | |
|
| | |
|
| |
|
