Frysk minutes 20060905

[Wu Zhou]

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 (http://sources.redhat.com/ml/frysk/2006-q3/msg00371.html).  Anyone can 
take a look and review.  Thanks.


Regards
- Wu Zhou