public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
* minutes of 2007-09-19 meeting
@ 2007-09-19 14:32 Elena Zannoni
  2007-09-19 15:03 ` Teresa Thomas
  0 siblings, 1 reply; 2+ messages in thread
From: Elena Zannoni @ 2007-09-19 14:32 UTC (permalink / raw)
  To: frysk

Frysk Meeting 2007-09-19

Sami, Mark, Stan, Phil, Elena, Rick, Tim.


Questions about shared library loading:
solib debugging flags: were added in gdb long time ago. Look at this
gdb branch: ezannoni_pie-20040323-branch

Roundtable
---------------

Mark: libunwind stuff: done merge of upstream libunwind. This is
before the ppc32 work in libunwind is finished. ppc64 stuff has been
merged into the frysk libunwind.

There are 30 local patches some of which should be upstream. Signal
unwinding is one of these patches.

After that's done will add the debugframe stuff. libunwind doesn't do
debugframe support not wanted upstream in libunwind

cross architecture builds are needed by frysk, where we link the 32
and 64 bit libunwind to do 32 bit unwinding together with 64
bit. Upstream doesn't do that. A local copy of libunwind is needed for
this reason.


Pearly: for now working on disassembler and memory window bugs. We'll
need to figure out the next task in a few weeks.


Kris: working on labrat improvements this week.


Phil: background reading on HW watchpoints. How the kernel sets and
clears the hw debug registers is a complicated matter, and varies btw
arches.


Sami: C++ scoping rules in frysk: added to frame object a function to
search according to scoping rules, and working on writing a search
engine for C++.


Tim: looking at bugs from last meeting when breakpoints are being hit.
cli needs to be notified in more circumstances than it is now.

Problems with multi threaded cases: stepping engine observer, function
gets called when step completed. in MT situations: currently only
report when all the threads have finished their steps, but if you are
to step into a function, one thread could end up blocking on a ptrhead
blocking call and it will never finish its step, the stepping engine
will not report back that the step has finished, because it has to
wait for all the threads. Should instead be notified wherver any
thread finishes a step, w/o waiting for all of them. Or something of
the sort. Still trying to figure out what the right thing to do is.

Importing history into GIT. Did a prototype of that. Was ablt to go
back at any point and rebuild the project at that point.


Stan:
split off the type evaluation from the exp evaluation. Type and value
are evaluated in different places now. No more monolythic routine, it is
now done in the class that correspoinds to the type. Short int eval is
done in the short int class, and so on. This enables the expression tree
generated by antlr to be annotated with types for each node of the
tree. Now each piece can have a type on it. Makefile assumed that
there was one antlr file, changed that to allow multiple antrl files.


Rick:
Some vacation. But working with Phil on corefiles, translate that to
the executable file, fhpd "load" command. Trying testcase, and refine
that. Hopefully will be done sometimes this week.
Able to look at memory location wthin an executbale.


Teresa:
OP_Piece: it's working for registers and memory as far as we know. Not
turned on yet. Sami reports that testing with that enabled results in
better test results.




^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: minutes of 2007-09-19 meeting
  2007-09-19 14:32 minutes of 2007-09-19 meeting Elena Zannoni
@ 2007-09-19 15:03 ` Teresa Thomas
  0 siblings, 0 replies; 2+ messages in thread
From: Teresa Thomas @ 2007-09-19 15:03 UTC (permalink / raw)
  To: frysk


> Teresa:
> OP_Piece: it's working for registers and memory as far as we know. Not
> turned on yet. Sami reports that testing with that enabled results in
> better test results.
The location code correctly decodes the location of the values, whether 
in memory, register or with a memory split. Facing two problems with 
manipulating variable values, (1) Getting variable values does not 
return expected value in 32 bit machines though it does this for x86_64. 
Examining the memory of the task in a 32-bit machine shows that it 
contains the LSB of the value at the decoded location, but the the bytes 
that follow are random. (2) Frame's setReg does not change the value of 
the register. So setting values is possible in memory but not regs.
Its probably not a good idea to enable the new location code atleast 
till (1) is fixed.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-09-19 15:03 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-19 14:32 minutes of 2007-09-19 meeting Elena Zannoni
2007-09-19 15:03 ` Teresa Thomas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).