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: libunwind progress


On Wed, Aug 16, 2006 at 10:44:27AM -0400, Adam Jocksch wrote:
> I've attached the patch to enable using dwarf_find_proc_info to be 
> applied in frysk-imports. This is how I'd recommend using it:
Hi, Adam,
Where is the patch? I could not find it in this mail. :)

dwarf_find_proc_info in libunwind could extract information about
cie/fde, and fill in dwarf_cie_info_t in void*
proc_info_t.unwind_info.  In parse_fde(src/dwarf/Gparser.c), 
proc_info_t.unwind_info is casted to dwarf_cie_info_t to get 
the start/end address of cie and fde.

> 
> 1) Build frysk normally
> 2) Apply the patch to frysk-imports.
> 3) Comment out the lines in frysk-imports' generated makefile that build 
> fryski and build frysk-imports
> 4) cd to frysk-core and 'make TestRunner'
> 
> You will probably also have to undo the patch that Rick brought in to 
> enable UNW_REMOTE_ONLY. The issue of the linker errors when building 
Yes, the first thing I do to make frysk core backtrace is to remove
UNW_REMOTE_ONLY.  libunwind could not work in a remote-only mode,
since information about dwarf/elf is all from local memory.

> fryski is something that needs to be addressed at some point. I've not 
> committed this patch because of the issues associated with using it. The 
> bugs for these problems are:
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=3068
> http://sourceware.org/bugzilla/show_bug.cgi?id=3070
> http://sourceware.org/bugzilla/show_bug.cgi?id=3071
> 
> Adam

Actually, frysk could do backtrace partially on my desktop with some
modifications to libunwind java bindings. (Here are some my thoughts to
libunwind, free to correct me if I am wrong.)

One of the most important changes is to implement the functionality 
of dwarf_find_proc_info in its java binding cni code
(populate_procinfo() StackCallbacks.cxx).  As I said above, dwarf_find_proc_info 
extract information about cie/fde, why don't we do the same thing in our
java binding cni code?  I add some code in populate_procinfo() to set 
start/end address of cie and fde.

Here is a list about the changes I did, for your reference,

1) Set return value of -10(-UNW_ENOINFO) instead of 0 in getDynInfoListAddr().
2) Set proc_info->unwind_info point to dwarf_cie_info_t* instead of
memory image of .debug_frame, and create a new member,
debug_frame_addr, to hold the memory image of .debug_frame.
3) Remove -DUNW_REMOTE_ONLY from CFLAGS in libunwind/configure.ac.
4) Hardwired as(address_space) to unw_local_addr_space in
run_cfi_program.
Index: frysk-imports/libunwind/src/dwarf/Gparser.c
===================================================================
RCS file: /cvs/frysk/frysk-imports/libunwind/src/dwarf/Gparser.c,v
retrieving revision 1.1
diff -u -r1.1 Gparser.c
--- frysk-imports/libunwind/src/dwarf/Gparser.c 31 May 2006 18:22:16 -0000      1.1
+++ frysk-imports/libunwind/src/dwarf/Gparser.c 16 Aug 2006 12:24:06 -0000
@@ -71,7 +71,8 @@
   void *arg;
   int ret;

-  as = c->as;
+  //as = c->as;
+  as = unw_local_addr_space;
   arg = c->as_arg;
   a = unw_get_accessors (as);
   curr_ip = c->pi.start_ip;

The test cases about ptrace in libunwind failed if I do this change,:-(
However, frysk could not do backtrace if I do not do so.  2) and 4)
are relative to Bug#3071, if libunwind could get the right fde/cie address
(done by 2), and access local address space instead of remote address
space (via ptrace) to get dwarf information(done by 4), this bug might
be fixed.

In fact, I am still not very clear about the general picture of
libunwind, and how frysk utilizes it, and sometimes suffered from
DWARF/ELF specification.  Any comments or advice is important for us to
understand libunwind, contribute to libunwind community, and to find 
an reasonable solution to libunwind java bindings.  Thanks!

-- 
Yao Qi


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