This is the mail archive of the 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: Frysk minutes 20060905

Elena Zannoni wrote:

Is anybody running on fc6? Phil is still yum updating. Please run make
check. Mark runs make check on fc6. Some improvements with the latest
patches from Roland. This is from last week. Are there anymore "the
whole machine hangs" kind of failures? Roland thinks no.
Are there more "make check errors" probably yes.

We are also running frysk and its testsuite on fc6. The shipped frysk in the .ppc64.rpm will trigger segmentation fault on fc6. We are now checking out and building the cvs source to see how they work.

libunwind: please test Alex patches. Andrew: to review. We can start
plug it into the sourcewindow, in the space reserved for it already.
The patches from Alex are not checked in yet. Please review and check
in asap.

We had a test. TestStackBacktrace works ok with this patch applied. But we have a concern that frysk-sys are using some synchronization mechanism to handle ptrace requests. This patch use ptrace directly. Is it possible some synchroinization problem might be introduced in?

For ppc64, we are having one engineer in US working on the porting. Anyway, it will lag behind x86 and x86_64. To make the later ppc64 merge-in more easily, could I request that we can isolate these architecture dependent code as early as possible? In fact, libunwind are already supporting x86 and x86_64. So at the design time, we need to give consideration to both. If some architecture dependent issues are identified, would you please also leave some space for ppc64 as well.

Did the syscall tracing get finished? ftrace you cannot track an
already running process. It can ftrace a newly created program,
started under ftrace. ftrace only works on x86, it doesn't really know
about the syscalls on other arches. Didn't IBM have patches for ppc?
It's just the syscall table missing.

32/64: Table for 32 bit syscalls on 64 bit machines, is different from
pure 32 bit case(?).  Mapping of 32-bit registers in 64-bit mode is
also different.  How do we test this? transition of a 64 bit to a 32
bit back and forth (forking a 32 bit from a 64 bit process and vice
versa). Lots of corner cases. Could IBM look at this for ppc? But Tim
should finish this as he started it.

We are thinking about the above two issues all the time. And we found they are not only specific on ppc64, they are problems of more general background instead. We are missing syscall table right now, but the current method to generate syscalls having its internal issues. Yao ever introduced a thread to talk about that. We would like to see more comments about his proposal.

The bi-arch support is also relevant. A good solution to handle 32-bit and 64-bit syscall at the same time can lead to a better bi-arch support. More tests are also needed.

Disassembly: should it go in the source window as well? Yes. As a
separate pane. This can be started now. Adam?

Yao had a patch about that ( Anyone can take a look and review. Thanks.

Regards - Wu Zhou

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