Hi Vasily,
I've put replies inline
On Mon 26-Dec-2016 9:37 AM, Vasily A. Sartakov wrote:
Greetings.
I have merged MIPS port with 4.0.0 release. Now I would like to clean up my
code and need to remove many small issues that I did not fix during the porting
before making the code public. In fact, most of the current problems are
related to toolchains:
1. The first problem is a position independent code. Could you please describe
me seL4' vision about it? muclibs is building with -fPIC, but everything else
doesn't, right? I have a very tricky set of GCC’ flags, related to MIPS’ GOT,
small data, abicalls, pic/non-pic, etc, and many of them are not working
together.
We do not have a particular vision for it, although if people want it we will
try and support it. Currently this amounts to our ia32 syscall stubs having the
option to be built to support PIC.
Is 'muclibs' muslc? As far as I can tell it only builds a couple of the crt
files explicitly with PIC.
I don't know much about MIPS, but for x86 as long as you are writing C and not
assembly then the compiler can built it as PIC or not. If MIPS is similar then
the choice to support PIC will just come down to what you want to do.
2. MIPS assembler has several features, one of them is that the -O0 code
requires having an addition space above the top of the stack for 4 registers:
43b610: 27bdffe8 addiu sp,sp,-24 <— start of the function
43b614: afbf0014 sw ra,20(sp)
43b618: afbe0010 sw s8,16(sp)
43b61c: afb0000c sw s0,12(sp)
43b620: 03a0f021 move s8,sp <— frame stack
43b624: afc40018 sw a0,24(s8) <— save 1st arg for a subroutine call
43b628: afc5001c sw a1,28(s8) <— save 2nd arg for the subroutine
43b62c: afc60020 sw a2,32(s8) <— save 3rd arg for the subroutine
So, each time when I am allocating new stack I should return not top of the
stack, but top_of_the_stack - 4*sizeof(seL4_Word). As result,
sel4utils_configure_thread_config becomes platform specific. Could you please
consider a possibility to put it into the «arch» as
sel4utils_arch_init_context, or add something like «sel4utils_arch_configure».
Also, it is important: this is an issue only for -O0 code, as far I see, -O2
uses different methods for arguments passing. I am trying to build toolchains
which do not use frame pointer this style for -O0 code, but I am not sure about
the result.
Isn't this what 'sel4utils_arch_init_context_with_args', called from
'sel4utils_start_thread' is for?
3. I really like how you redesigned declaration syscalls. Now I have a freedom
to modify syscalls and do not care about the mainline declarations because now
there are syscall wrappers. However, my toolchain generates very poor code for
CONFIG_LIB_SEL4_PUBLIC_SYMBOLS and «DEFAULT» — I have proper working code only
for CONFIG_LIB_SEL4_INLINE_INVOCATIONS. What is the conceptual difference of
these declaration attributes, what they affect?
CONFIG_LIB_SEL4_PUBLIC_SYMBOLS is for when you would like the syscall functions
to end up in libsel4.a, such that you can link against it and call them from,
usually, languages other than C.
Not enabling CONFIG_LIB_SEL4_INLINE_INVOCATIONS results in kernel invocations
not being inlined, although the actual syscall stubs themselves should still be
inlined. The ability to not inline invocations was to allow for some
verification analysis to be done at one point in the past.
4. Could you please tell me what was the C equivalent of this asm code:
.global __syscall
.type __syscall,%function
__syscall:
sub sp, sp, #4
push {r5,r6}
adr r5, 1f
ldr r6, 1f
ldr r5, [r5,r6]
str r5, [sp, #8]
pop {r5, r6}
pop {pc}
.hidden __sysinfo
1: .word __sysinfo-1b
something similar to __syscall6 from libmuslc/arch/<arch>_sel4/syscall_arch.h,
right?
I believe that is correct, yes.
Adrian
_______________________________________________
Devel mailing list
[email protected]
https://sel4.systems/lists/listinfo/devel
