This is the mail archive of the
frysk@sources.redhat.com
mailing list for the frysk project.
Re: minutes 2006-09-26
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Wu Zhou <woodzltc at cn dot ibm dot com>
- Cc: Stan Cox <scox at redhat dot com>, frysk <frysk at sourceware dot org>
- Date: Mon, 02 Oct 2006 08:45:17 -0500
- Subject: Re: minutes 2006-09-26
- References: <4519639B.8010407@redhat.com> <1159461704.15957.21.camel@multics.rdu.redhat.com> <451CDC51.8090204@cn.ibm.com>
Wu Zhou wrote:
Stan,
Thanks for the minutes. All of us in China will begin the vacation
starting from 10/1... will get back at around 10/8.
Phil,
we are also interested in fcore and other little utilities, we are
very happy to know if there are any progress on that.
Stan Cox wrote:
Good morning.
The work has just begun, here is what I am doing. I am reading up on the
ELF Spec found here:
http://www.freestandards.org/spec/book/ELF-generic/
and also looking at how the kernel dumps the core.
The first part, and possibly the easier to accomplish (I might regret
saying this) is writing out the core file from a running process. If we
assume a core file is:
- elf header
- segment table
- .notes segment
- writable segments from maps
then we have a lot of that information already being modeled in the
frysk-core. What we don't have is .notes section. Have to study the
composition of that, and where that information can be derived from.
Problems blocking core file writing at the moment:
- We have to block all tasks in a proc first. Mike Cvet is
working/looking at that right now, but the mechanism is not there yet.
All tasks have to be blocked to make sure the core is a snapshot of the
process at that time.
- .Notes. What goes in and how do we access that information?
I expect fcore will mirror the fstack/ftrace programs in structure.
Further on the down the line is the reading of core-files into the
frysk-core, and modeled there (so the ui, or other utilities can
inspect it). As a core is not part of the system that frysk is modeling,
we have to construct a place for a read and constructed core-file to
co-exist. This probably means constructing:
DeadLinuxHost
DeadLinuxProc
DeadLinuxTask
All of those would have the same common superclass as thier "live"
counterparts, though I expect a substantially reduced api, and few if
any states.
So that is a 5 minutes status of the work ahead, and where I am at this
time. Hope that helps!
Regards
Phil