Elena, Phil, Mark, Mike, Nurdin, Sami, Rick, Tim, Cagney, Stan Phil: corefiles. --------------- It may have been abstracted at the wrong level. wrt to 32 bit vs 64 bit isa. Is there any refactoring that can be done? Different level of concrete classes with different level of abstract classes. Where is the sensation that it's wrong coming from? Has to map how host was refactored, linux ptrace task and linux proc task, isa should follow the same structure. Right now the isa is modeled after Ptrace Hosts, making assumptions on that would be incorrect for remote debugging, for instance. a refactoring for x86 and x86-64 would require about 5 or 7 new classes, if we consider other arches, there will be many more. remote should be considered too, it just won't work with the isa as it is now at least we have only Linux to worry about. Idea is to have an abstract factory that would return the appropriate ISA (ptracei386 or corefilei386, depending on the case). --> Discuss on mailing list ptrace and waitpid: ------------------ have the code do a blocking wait on waitpid always. sigchld: would call waitpid and drain the events. No relation btw sigchld ans waitpid. If you are tracing multiple processes or you have multipthreaded code you cannot rely on a specific semantic. So you need to change the code to be blocking. This would eliminate the hanging of testsuite runs: case where get signal, do polling wait, but there is no event from kernel. Out of order creation of the child: child has stopped and this signal arrives before frysk gets the event from the parent that the child has been created. This is one case of hanging. Wait is occurring on a thread different from the one that did the attach. Mark suggests using waitid(). Andrew is working on this libunwind: ---------- Nurdin is working on this. Working on accessors methods. multiplatform unwinding, bindings have changed. unwinder accessor methods are being rewritten. access registers for instance so that they can work cross platform for 32-64 uses ptrace accessors, this should be avoided. Local patches: have not been accepted/reviewed into libunwind. There are a lot of patches that are still local. Attach those to bugzillas against libunwind. linking statically: ------------------ so it can run both in build tree and install tree. Otherwise you would have to specify which shared libraries to use (build tree shlibs vs installed shlibs). (see rhel4 frysk installation) See Tim's mail about problems with reflection. Reflection api will not find classes at runtimes because they are not used. Look at interpreted version of frysk, to see how to do the linking. Roundtable: ----------- Kris: almost finished with the test&build system. Found problems in make dist will send info later today. Still aiming at working 64 bit gui problems afterwards. Sami: observer redesign. Removing dead processes. Cleaning out old code. Then redesigning the gui. Mark: stepping & breakpointing. Cleaning up. Out of line breakpoint. Add something to proc to do requests on a set (or all) Tasks of a proc. Send event to proc and then from proc to task makes a couple of things easier. In a couple of cases it's hard to track what state a task is in, for instance if a task disappears. Alternatively send event to proc and from there to task. Rick: bring up taks in source window, stick at trap at main(). Set up a terminal window at the bottom with the task output in that. Hooking up all the pieces. This is both for the monitor (bug 1492) and the source window. Initially stop at the first intruction instead of main. It would be simpler. Mike: hpd improvements, variable inspection for multithreaded programs (in sourcewindow). Working on multiple processes for source window. And load up backtrace. Phil: corefiles: you can load them, look at register, now model a corefile as next task. Tim: breakpoint on inline function, bp based on names of function. Working on DIE wrappers. Stan: added enums. assignment of integer variable with enum elements, still not working. Next week ---------- GUI: Mike: assembly and source in source window, and possibly multiple processes in the source window. Also demo of observer stuff from Sami.