Andrew, Mark, Tim, Elena, Phil, Rick, Adam, Teresa, Sami. cni-> jni code because cni will not be supported any longer. Jni not as efficiant and straightforward. Are there performance issues? If so maybe move the bindings to a higher level into the core. Move more stuff to C++. Mark: CNI: you can just access a field. C++ and Java part will be the same. If there is an array[], lock the array, ask for the element, java array-> c++ array, lock again, put the element, etc. Much more cumbersome. Java side more efficient, but for any access you have to convert any data to c++. Simple data type-> convert into integers. Even string converting is kind of complicated. Callbacks: C code calling Java code: Same thing: cannot just call a Java method. first have to ask the class of the object, then the identifier of the function, then the types, then call it. So also this one not easy. Beyond native function calls, it quickly gets inefficient. You can do caching. If you move a lot into the C side and do not call back on the java side, then return only one result and do calculation on java side then it's not too bad, but small methods, and lots of cross language calls, is very inefficient. No good reflection because using CNI, if JNI used reflection is better. Fix is maybe prelink everything into a .so lib so that nothing gets lost. Elf bindings have serious memory smashing, Reproducible: exception thrown -> stdin gets closed. Elfutils clobbers memory leading to a FD being closed. Bindings are complex at the moment, JNI would add further to this complexity. This would also move us away from gcj. JNI: you also pass around the whole Java environment, the entire context. Java Gnome is JNI code. JNI: code is part of the VM that is in the executable, it's an interpreter. Interpreter has the machine in itself. Environment is a pointer to the VM, plus some more stuff. This will force us to have thinner bindings. (see java gnome bindings, are thinner). When is this change going to happen? Around end of 2007. CNI users: Frysk, libgcj Roundtable: ---------- Teresa: new implementation of finding debuginfo. Change design pattern. libdwlf use something higher level and not do deep into the library. Interface change for looking up the debuginfo. Refactoring, and split it up, oo it becomes easier for other users to plug into it, if needed and easier to customize it. Elfutils calls this code. Pulling separate debuginfo is currently inefficient. Computing CRC multiple times. Maybe use Hash to match debuginfo and executable instead. Sami: print values of vars and params. Found bug, fixed it. Printing var and values from previous frame. Pretty much done, except for 64 bit bug printing variables. Code is not command line specific. Mark: finishing the step out of line framework. Chasing a bug. Display value test fails -> Adam's code. Fails an assert. Frysk doesn't pull all breakpoints. Rick: CDT parser problems. Macros handling related. Pull in new version of the CDT parser soon. How tightly integrated is it with the eclipse core? Rick asking the eclipse people to see if they can split it up more. Filed soe GUI bugs, working on those. Moving session manager where both gui and cli can get at it. THey both can be session aware. Eggtray icon seems to have disappeared on fc6 and fc7, visible on fc5. Phil: testing 32 bit corefiles and 64 bit core files also on cross platforms. And with different endiannes. 32x64 bit tests are disabled for live 32 bit processes on 64 bit platforms. Can this be re-enabled. Use --arch to enable. Nurdin is comfortable with doing this. Also you can run the whole testsuite twice. But Andrew suggests to just do the first one for now. Tim: look at breakpoints for different processes and threads for the HPD. Tim working in RT, could go anywhere, Andrew says move it to frysk.session. More refactoring! Adam: working on display command on HPD. Include actionpoint commands increase robustness and making it match the spec. Andrew: Elfutils: problems with exceptions. libunwind bindings: exceptions thrown: reduced the number of cases. Code no longer thowrs exceptions, if it does it will be java exception. Elf objects are held on for a long time. How long are they around? the FD is held on. Should look into that. dwfl cache is now per therad. It cleans up at the end of each testrun. There are no dwfl objects left around. Code is still relying on dwfl objecs being open for a long period of time. Cache algorithm is simple minded. Nurdin looking at this. Correct alg. is to clone the dwfl to contain the latest proc information. Dwfl will remain open but internally will be more eficient. Why cannot dwarf contructor open its own elf object? Managing of dwfl, dwarf, elf objects seems not optimal. SHould be audited.