Sorry for the delayed reply! Other things have been getting in the way, and some mild illness certainly hasn't helped matters.
On Wednesday 25. October 2017 00.42.59 Adam Lackorzynski wrote:
On Mon Oct 23, 2017 at 01:50:47 +0200, Paul Boddie wrote:
I haven't looked at how the floating point emulation is done in the Linux kernel, as another example of this kind of thing, but I imagine that you have
Linux has FP emulators to support applications with FPU code on processors that don't have an FPU. It does the obvious, catching the traps and handling them. Whether it's a good idea to do that in a microkernel is another thing. Technically it could be done of course but building the code with softfloat has always been a good alternative.
I'll most likely take the soft-float route for other SoCs when I get round to looking at them.
to do some assembly language programming here just to recover from the exception. In this case, however, the emulated instruction is very simple, although I did take the liberty of rearranging the emulation mechanism slightly.
Yes, it is probably simple but that does not necessarily mean it would need to be done in asm. Exceptions are caught and handled of course, the actual processing can be done in C.
The instruction being emulated is rdhwr with argument $1 (SYNCI_Step). Other arguments of this instruction were already implemented in src/kernel/fiasco/src/kern/mips/exception.S, and so it was natural to add support for this argument there as well. For example, the existing support covered argument $29 (ULR) which seems to be concerned with accessing task/thread-local storage, if I interpret "TLS" correctly.
Meanwhile, argument $1 (SYNCI_Step) is concerned with accessing data from a configuration register that would normally only be accessible in kernel mode, with the purpose of this instruction variant being to expose the cache details to user mode. So the only way to actually implement the instruction as intended would be in kernel mode by doing the necessary read from the CONFIG1 register.
A hack that I did consider was to just replace the instruction with code that just loads a constant that is set up according to the SoC parameters. A user space handler could certainly do such work and be invoked by the exception handler, but the resulting functionality would not exactly be equivalent to that provided by the patch because it would not dynamically ask the hardware about itself.
[...]
Yes. Various L4Re components do not work when compiled with gcc unless I introduce these changes. It was suggested that I do not compile such things as position-independent code, but I don't remember any further explanation.
Hmm, does that mean that with Debian's gcc (6? 7?) there might be issues?
Here's my version information:
mipsel-linux-gnu-gcc (Debian 6.3.0-18) 6.3.0 20170516
However, I was told that gcc typically compiles position-independent code as the default for mipsel. My guess is that any version would be a problem, and I think it was already noted that development was done with the MIPS vendor compilers, not gcc, so this is why this issue wasn't noticed before.
[Accessing 1GB]
Ok, I see, there's a background. And obviously the available memory can make a big difference.
If the entire 1GB appears at a different physical address than zero, which is my understanding of the situation, is it possible to set some kind of configuration variable to let Fiasco know about this, while still preserving the addresses used for things like peripherals in the usual zero-based region?
Paul