On 08.10.2010, at 15:23, Andreas Färber wrote:
Am 08.10.2010 um 14:54 schrieb Alexander Graf:
On 08.10.2010, at 14:44, Andreas Färber wrote:
I've gotten AIX 6/7 to instantiate RTAS (patches upcoming) and would like to trace what it's trying to do. I probably need to implement the display-character token.
As you're running in qemu, the gdbstub is very helpful at times.
Not too familiar with gdb, can I use Apple's host gdb for that? I believe Blue once said something about gdb not working in *-elf configuration and requiring *-linux instead?
You can use the apple gdb without an object file, so you don't get symbols. But if you have an instruction pointer, just
$ qemu-system-ppc -s -S ... (gdb) target remote localhost:1234 (gdb) b *0x1234 <- address of rtas_something (gdb) c
It should break on that IP and then you can evaluate the register contents at least. Either by
(gdb) info registers
or
(qemu) info registers
The RTAS code in arch/ppc/qemu/start.S currently looks like this:
GLOBL(of_rtas_start): blr GLOBL(of_rtas_end):
...and I would like to branch to C code from there.
Is there a way to have code from, say, rtas.c go between the blr and of_rtas_end symbol? Or do I need to move the symbols to the ldscript and place the code in a special section? If yes, how?
Why do you want to have the code in between? You can just branch to the C code:
b c_rtas_function
The only thing you need to make sure is that you follow the ABI :). Input parameters go in r3-rsomething, output is in r3, stack pointer (r1) has to be valid.
Also by only doing the b instead of blr you jump to the C function directly, so a return from there actually returns from the rtas function.
If the rtas function follows a different ABI, better set up a stack frame and blr into the C function.
I assumed the latter is what I should do, following the CIF example.
Those symbols are being used for code size calculation and relocation in arch/ppc/qemu/methods.c.
Maybe I don't really understand the question though.
Thanks for promptly trying!
The code in methods.c basically does a memcpy() of of_rtas_start..of_rtas_end to memory that AIX allocates for us. The code is never called at its original location so needs to be PIC. Thus, if the C functions are not copied along, any relative addressing wouldn't work and absolute addressing would break as soon as the functions get unmapped. You might think of it as a "separate" executable that OpenBIOS loads and sets up. Therefore I need a way to get one piece of memory containing the entry point, data storage and all helper functions called.
Oh. That's not exactly easy. So the rtas space stays intact while all the openbios functions it wants to call don't? Hrm.
I guess you'll have to copy them down too, which can become very hairy very quick. Why don't you just create a separate binary for RTAS which can then use relative branching inside of itself? You could then copy the whole blob somewhere and be sure that everything's there.
Alex