Hello.
I have a problem. It is a very complicated problem. I understand that It is hard to give an advice without looking into the sources. But I am stuck and need some ideas in ‘brainstorm’ format as an input for me. So, here is the problem:
There are many tests from sel4test suit are working. This is how does it look like:
http://pastebin.com/vvnDaUe9
Unfortunately, I found several configurations of the tests, which causes crashes with stable and different symptoms. One of them is looking following:
11 #include
On Tue 01-Nov-2016 7:37 AM, Vasily A. Sartakov wrote: as you might see, this is little bit modified version of trivial.c tests. Usual, when I am testing all tests, there is no problem with this test. But when I am running this file alone, I have a problem. Also, you might see, that there are several free lines with numbers from 16 to 22. I made this not accidental, it is a source of error. If the test_allocator(env_t env) is lockated in the 23rd line, this tests has no problem. But if I add one more free line, I have an error like this: If adding whitespace gives you a different compilation result then that is one bizarre compiler you have. I would check and make sure that this is really what is going on, because it seems fairly improbable to me. Maybe do some multiple runs/builds, 'make clean' between each build etc. Also, I see, that there is a correlation between size of the image and faults: 1349892 ./sel4test-tests.bin_23 1349900 ./sel4test-tests.bin_24 The border line is 1349900 if I have a size of the image below the value -- there is no problem. Unfortunately, 1349900 is not a 'round' value, somehow related to TLB sizes of something else what I know. If virtual address layout changes seem to coincide with faults then I would be checking things like * Context switching code / address space management * TLB/cache/ASID maintenance * Branch predictor / any other hardware state that tracks virtual addresses Note that I'm saying this as someone who knows basically nothing about MIPS, hence the broad suggestions. Adrian
I think I found the reason, or, at least, I do not have errors now and I have reasoning about the solution. Please correct me if I am wrong. Firstly, I should come back to my email about syscall.c (11 Oct. 16). This conversation was started by my message: … For example, sometimes it uses only S0-S7 with some T0-T9 registers … end ended with: ------
The point of the syscall.c tests is to check that registers are not being corrupted by our syscalls (i.e that the kernel ABI + stubs follows the calling convention of the architecture).
…and corruption of registers can happen only if syscalls modify stack, since these values are popped from it after the end of a syscall routine, right?
-----
So, I have tried to say, that this test, in my case, tests nothing, because variables like this:
register int a00 = 0xdead0000; \
register int a01 = 0xdead0001; \
register int a02 = 0xdead0002; \
register int a03 = 0xdead0003; \
register int a04 = 0xdead0004; \
can be located anywhere. Since I (we/you/they) do not specify exactly register name, the compiler can do anything with these variables. And this is what I saw in my tests: My compiler uses different registers and save their values on the stack before the syscall. After the syscall, the compiler load previous values, and tests pass without any problem. Now I have specified register name:
#define TEST_REGISTERS(code) \
do { \
register int a00 asm("v0") = 0xdead00aa; \
__asm__ __volatile__ ("" \
: "+r"(a00)); \
code ; \
__asm__ __volatile__ ("" \
: "+r"(a00)); \
test_assert(a00 == 0xdead00aa); \
} while (0)
and used only Yield syscal as the test. Btw, this is an implementation of Yield:
static inline void
seL4_Yield(void)
{
register seL4_Word scno asm("v0") = seL4_SysYield;
__asm__ __volatile__ ("nop;syscall" : : "r"(scno));
}
And this is what I see when I disassemble this test:
00403080
On Tue 01-Nov-2016 7:37 AM, Vasily A. Sartakov wrote:
as you might see, this is little bit modified version of trivial.c tests. Usual, when I am testing all tests, there is no problem with this test. But when I am running this file alone, I have a problem. Also, you might see, that there are several free lines with numbers from 16 to 22. I made this not accidental, it is a source of error. If the test_allocator(env_t env) is lockated in the 23rd line, this tests has no problem. But if I add one more free line, I have an error like this: If adding whitespace gives you a different compilation result then that is one bizarre compiler you have. I would check and make sure that this is really what is going on, because it seems fairly improbable to me. Maybe do some multiple runs/builds, 'make clean' between each build etc. Also, I see, that there is a correlation between size of the image and faults:
1349892 ./sel4test-tests.bin_23 1349900 ./sel4test-tests.bin_24
The border line is 1349900 if I have a size of the image below the value -- there is no problem. Unfortunately, 1349900 is not a 'round' value, somehow related to TLB sizes of something else what I know.
If virtual address layout changes seem to coincide with faults then I would be checking things like * Context switching code / address space management * TLB/cache/ASID maintenance * Branch predictor / any other hardware state that tracks virtual addresses
Note that I'm saying this as someone who knows basically nothing about MIPS, hence the broad suggestions.
Adrian
-- Vasily A. Sartakov sartakov@ksyslabs.org
participants (2)
-
Adrian.Danis＠data61.csiro.au -
Vasily A. Sartakov