| 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>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
It seems like the linker now splits sections in pieces that may be smaller than a page, causing the
loader to try to load the same page multiple times and fail. Now, offsets are handled properly, and
loading of the new kind of files work properly. If the first part of the page is read only, and the
second is read-write, then the entire page will not be read-write, which could cause issues. At the
moment, it seems this only happens for the text section, which is read only anyway, so it should not
be a big issue in the near future at least.
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>
|
| |\
| |
| |
| |
| | |
Fixed typo in standalone lab3, ptree -> pstree
See merge request klaar36/pintos!12
|
| |/ |
|
| |\
| |
| |
| |
| | |
Added 'close' test for better testing of syscall parameter validation.
See merge request klaar36/pintos!11
|
| |/
|
|
| |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |\ |
|
| | |
| |
| |
| | |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| | |\
| | |
| | |
| | |
| | | |
Fixed compilation issues on the latest GCC and QEMU.
See merge request !10
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| | |\ \
| | |/
| |/|
| | |
| | | |
Fixed compilation error of sc-bad-write in GCC 7.4.
See merge request !9
|
| | |/
| |
| |
| | |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| | |\
| | |
| | |
| | |
| | | |
make pintos-script perl 5.26 compatible
See merge request !8
|
| | |/ |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed sc-bad-write once again...
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>
See merge request !7
|
| |/
|
|
|
|
|
|
|
|
|
| |
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>
|
| |\
| |
| |
| |
| |
| |
| | |
Fixed sc-bad-write test to be more precise.
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
See merge request !6
|
| |/
|
|
| |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |\
| |
| |
| |
| |
| |
| | |
Fix up exec-corrupt to accept exit(-1) anywhere, make sc-bad-write reserve space…
… for 3 parameters instead of 4
See merge request !5
|
| |/
|
|
| |
space for 3 parameters instead of 4
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix for possible bug in exec-missing.
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>
See merge request !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>
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| |\ \ |
|
