This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: the results of TestRunner on PPC64/FC5


Sorry to not reply immediatly;
Wu Zhou wrote:

On Wed, 8 Mar 2006, Wu Zhou wrote:


In directory frysk-core, there are four case failures:

frysk.proc.TestI386Modify, frysk.proc.TestI386Regs, frysk.proc.TestSyscallOpen and frysk.proc.TestSyscallInterrupt

[root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestSyscallInterrupt
Running testSyscallInterrupt(frysk.proc.TestSyscallInterrupt) ...ptrace: Input/output error
[root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestSyscallOpen
Running testSyscallOpen(frysk.proc.TestSyscallOpen) ...ptrace: Input/output error
[root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestI386Modify
Running testI386Modify(frysk.proc.TestI386Modify) ...ptrace: Input/output error
[root@plinuxt2 frysk-core]# ./TestRunner frysk.proc.TestI386Regs
Running testI386Regs(frysk.proc.TestI386Regs) ...ptrace: Input/output error

Didn't look into these failure yet. Just post the problems here for recording. If anyone could give me any hints, that will be much appreciated! :-)


I made a little analysis on these failure. And find these EIO error of ptrace come from the fact that member function sendrecIsa of LinuxTask is hard-coded to call LinuxIa32.isaSingleton (). So maybe we need to change
this?




Looking locally, the ptrace barf is easy to fix (it should throw an exception :-), however, yes, the isa issue is more complex.

First, sendrecIsa need to be dependent on the target ISA. This can be ia32, x86-64, ppc64, or some others maybe.



Yes.

The information needs to come from the kernel's process tables. Unfortunatly there is currently no such interface - http://sourceware.org/bugzilla/show_bug.cgi?id=2458 . Fortunatly, there's a work-around. It is possible, using heuristics, to get the information from /proc/<pid>/auxv, take a look at frysk/sys/proc/Aux*

Second, we need to add a class named LinuxPPC64 to extend Isa to support PPC64 (maybe a class named LinuxX86-64 is also needed. I am not very sure though). But I have a few question here:



Yes. Presumably each ISA would register itself with LinuxHost so that sendrecIsa, given a process and its auxv, would be able to find and return the correct ISA.

A. what is the bank intended to represent in class Register? I see that all the registers in LinuxIa32 set its bank to 0.



For the ia32, there should be at least three banks (I'd better check what was actually implemented):
- integer registers
- floating point registers
- sse registers
A bank is a ByteArray containing the raw register information. How many banks there are, and their structure, are entirely ISA/OS/ABI dependant - determined for instance by the layout returned by PT_GETREGS, or /proc/<pid>/tasks/<tid>/regs.


The second ISA specific areas are the system call, and signal descriptions. At present they are very hard wired, I think they should be drawn from tables. The current code is a prototype.

B. class Isa seems to be not completed yet. So what is it intended to cover? ISA dependent features? or even include OS specific stuff? I see
there is a segment of comment, saying:


/**
* Instruction Set Architecture.
*
* XXX: This ISA object needs to be re-organized; perhaphs an OsIsa
* object with nested members for the ISA, the OS, et.al.
*/

So Frysk is also intended to support other OS? I had thought that it is only for Linux.



frysk is being developed on GNU/Linux, yes; in the future, who knows. Even within Linux, there are warts - while upstream settles downstream can find itself with local variation that bubbles into these interfaces. A local system call, for instance.

Consider the system

And what is label "XXX" intended to represent? In my knowledge, that place is usually occupied by the author name. :-)



Very old convention. It is acting as a marker for stuff that is broken or missing or needs work.

BTW. I also see XXX is used in many other places, such as host.requestRefreshXXX, host.observableProcRemovedXXX.addObserver, and so on... Any intention on that?



Don't use it :-)

Regards
- Wu Zhou

P.S: I ask a lot of questions in one mail. Forgive me if it overwhelms. I am curious indeed. :-)




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]