public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Elena Zannoni <elena.zannoni@oracle.com>
To: frysk <frysk@sourceware.org>
Subject: minutes of 2007-09-19 meeting
Date: Wed, 19 Sep 2007 14:32:00 -0000	[thread overview]
Message-ID: <46F13329.6000406@oracle.com> (raw)

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.




             reply	other threads:[~2007-09-19 14:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-19 14:32 Elena Zannoni [this message]
2007-09-19 15:03 ` Teresa Thomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46F13329.6000406@oracle.com \
    --to=elena.zannoni@oracle.com \
    --cc=frysk@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).