Hello, Stuart,
I am reviewing source code of the emulator and found the following
issues needs to be resolved before running user mode test program.
Since I am not familiar the internal of the QEMU, I am just
pointing out the problems.
Please forgive me if you already noticed the problems.
(1) Stack management
PA-RISC stack grows up (increasing to higher address), while other
architecture’s stack including x86’s grows down (decreasing to
lower address).
So the stack populating, management code such as setup_arg_pages
(linux-user/elfload.c), create_elf_tables(linux-user/elfload.c) in
init_thread(linux-user/main.c) and loader_build_argptr(linux-
user/linuxload.c) needs to be reconsidered. You can refer to the
Linux2.6 kernel fs/exec.c setup_arg_pages() #ifdef
CONFIG_STACK_GROWSUP part for example.
(x86 and other architecture)
-----Low -----
^
^
||
stack_start
argv, envp
stack_end
----- High -----
(PA-RISC)
-----Low -----
stack_start
argv, envp
stack_end
||
V
V
----- High -----
(2) System call gate
The current emulator code does not have system call gate handling
and it is not possible to run the user program.
In the QEMU, it looks to me the system call entry is picked up in
the cpu_loop(linux-user/main.c) where real system call detection is
in cpu_exec(cpu-exec.c).
PA-RISC system call gate is implemented using gate instruction at
gateway page 0xb0(lws_entry), 0xe0(set_thread_pointer), 0x100(system
call entry). I think there are two ways to detect system calls from
the normal instruction emulation sequence.
I am not sure which one is better.
(a) system call entry instruction in the glibc is like this:
BLE 0x100(sr2,r0) ;Jump to system call entry point
LDO system_call_number, r20
So if we handle BLE 0x100(sr2, r0) instruction specially, we can
detect system call.
The binary representation of this instruction can be found as
INSN_BLE_SR2_R0( Linux 2.6 arch/parisc/kernel/signl.c)
(b) If the instruction pointer goes to 0xb0, 0xe0 or 0x100, we can
detect it as system call entry.
- Tomonori Yamane
|
