This is the mail archive of the frysk@sources.redhat.com mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: add two accessors to Syscall


On Mon, Aug 14, 2006 at 07:28:33PM -0600, Tom Tromey wrote:
> I was reading a thread on the valgrind list about finding where a bad
> close() was called
> 
>     http://article.gmane.org/gmane.comp.debugging.valgrind/5996
> 
> and I thought this would be a simple thing for frysk to do.
> 
> First I wanted the appended patch to let my code inspect a Syscall.
> Could someone check this in?  (I didn't add all the accessors, just
> the ones I needed.)
> 
> I hacked up ftrace.java to do what I wanted (it was *very* easy this
> way -- nice :-), but on my FC5 box I always get an I/O error when
> trying to get the stack trace of a task (failure attached).  Any
> ideas?
In the log, I find that,
......
......
   at inua.eio.ByteBuffer.getInt(fdtrace)
   at frysk.rt.StackCallbacks.accessMem(fdtrace)
   at lib.unwind.StackTraceCreator.unwind_setup(fdtrace)
.....
.....
libunwind could not work with frysk core, and its java binding could
not do backtrace.  Here is a bug about it.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2936

We are investigating the libunwind internals, and find that, libunwind
could be divided to four parts logically, ptrace, unwind, dwarf/elf,
and target, but unfortunately, ptrace part is closely-coupled with
dwarf part and unwind part.  It is hard to replace ptrace in libunwind
with PtraceThread in frysk core via java binding.  We will post our
proposal here when we make it more clear.

Here is one problem about libunwind we met, if anyone here could
explain them for us, thanks very much.

unwind table.
What is the meaning of this?  I searched it in DWARF3 specification,
but little could be found.

> 
> Also I noticed a few other oddities here and there.  For instance,
> SyscallEventInfo.returnCode returns a long -- but apparently does not
> sign-extend the syscall's actual return value.  This leads to the
> unobvious test:
> 
>     (int) syscallEventInfo.returnCode(task) < 0

SyscallEventInfo.returnCode is only a abstract method that should be
overridden in sub-class, such as in LinuxPPC64, LinuxPPC, and LinuxIa32.
The return code is sign-extended in LinuxPPC64 at least.

> 
> I wasn't sure whether you'd prefer email about little things like this
> or whether I should just drop stuff directly in bugzilla... let me
> know.

It is easy to track the bug in bugzilla, but not everyone here could
be notified when bug is filed or updated.  It is great, if we could
post the information about the bug in maillist after we open it in
bugzilla.

> 
> Tom
> 




-- 
Yao Qi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]