public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Elena Zannoni <elena.zannoni@oracle.com>
To: frysk <frysk@sourceware.org>
Subject: Meeting minutes 2007-07-25
Date: Wed, 25 Jul 2007 15:25:00 -0000	[thread overview]
Message-ID: <46A76B91.60702@oracle.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 142 bytes --]

Apologies for not sending minutes last week, I didn't have a chance to 
attend the meeting.
Here are the minutes for today's meeting.

elena


[-- Attachment #2: frysk-20070725 --]
[-- Type: text/plain, Size: 4647 bytes --]

Minutes, frysk meeting 2007-07-25

Mark, Phil, Rick, Teresa, Nurdin, Sami, Stan, Elena, Andrew, Kris


Andrew:

code shuffling. Break down into command tests in fhpd. Add new
commands, then add tests in individual files.

frysh-asm.h proper markup for unwind information -> tests can be written
to have correct stack frames.


Teresa: display debuginfo for attach. Make sure it works with new
frysk imports make another utility to install missing debuginfo
packages, using yum.  fdebuginfo and fdebugrpm are the names.


Stan: vacation last week. Changed expr parser to pass in the frame,
changed callers too. Static frame notion: no more. Deal with the frame
passed in. Changed the trigger char for break, it is now '#'. Fixed
problem in parser. Break #file#linenum is the new syntax.
Does syntax for breakpoint require # in front of file name as well as
in front of line number? Yes.


Rick: source window. Parser problem with bash. No way to solve with
current parser. Added code to work around problem. If parser errors out
added element to dom in case of error which will pop up source code
unmarked (ie w/o highlighting). Ie source display still functional. 


Phil: last corefile task. Refactoring fcore. Using factory.  Question:
9 classes instead of 1. Where to put them.  Classes are specific to
fcore. There are specific cases for handling registers on different
architectures.  No mechanism to dump core files from the GUI.  Andrew
suggests to have a library to provide mechanism to do core file
manipulation. 

Kris: modeling state machine for stepping engine to make sure we are
not missing anything also working on most recent testsuite hangs. fd 0
being open and closed unexpectedly. Making labrat more robust to cope
with hangs. Killing testruns will have to happen.

Pearly: working through bugs for memory window.

Mark: reproduced weird bug and have testcase and workaround. No
complete solution yet. It happens when you do single step over current
instruction at bp location. Pending signal comes in, so you go
into the signal handler. Set bp to be stepped, then you do ptrace
single step, instead of single stepping that instruction the process
gets the pending signal.  Testcase makes it pretty clear. Very time
dependent.

Report that there is a signal pending, then next time around attempt
to do a stepping with signal. Client would be notified that there is a
signal, then notified that there is an instruction (1st inst of signal
handler). Not try to step right away. Signal pending -> signal delivered.

Signal mask can be examined in /proc/<pid>/status, but there is race
condition obviously when reading it.

Memory: adding external command to fhpd. No time to do this this week.

Sami: variable printing stuff added to fstack. Fixing bugs related to
libdwarf bug, talk to Roland about what to do there.  Moved
fstack to use PrintWriter, instead of strings. If you need a string
you can wrap it. When crashing-> didn't use to print the info so
far. Now it prints out up to where it is at. So you can diagnose where
it crashed.

Demo on vncviewer --> Mark to post the output.

Some problems printing strings. 

"fstack -a" prints name of solibs, "fstack" doesn't. --> make it do
that for "fstack" too.



syntax examples:

foo.c:12 --> file line number in gdb

'foo(int)' --> gdb needs single quotes to disambiguate C++ functions
or classes from C types

foo+#/usr/include/ld.h#global_var --> qualify variables in expressions

{int i; {int i; { int i;}}}



Nurdin: disassemble in cli.

puts '*' at current location

can give argument Hex address *should* disassemble around that
address-> doesn't work in the demo.

can give 2 addresses: display btwn the two addresses.


gdb can disassemble a function (given as argument), can frysk do that? no

doesn't seem to be able to disassemble from a core file.

live debugging session of frysk itself. 20 minutes. 

there is a '*' in the "list" output as well. --> bug" '*' should be in column
0, not after the line number.


Breakpoint setting in gdb vs frysk: "break foo" -> results in 2
different places in frysk vs gdb.

gdb:
break *foo --> at start of function (before prologue)
break foo --> at end of prologue (at first instruction of the body)


frysk meaning of break foo is the same of break *foo in gdb.

Stan reports seeing bigger diffrences between bp locations in gdb vs
frysk for C++. Possibly not accounted by the *syntax.


Phil: disassembly of core file should be the same as a live process,
as long as $PC was stored correctly. What broke? Something in fhpd,
seems likely.


Next week topics? Not understandable on the phone. Please somebody
fill in





                 reply	other threads:[~2007-07-25 15:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=46A76B91.60702@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).