This is the mail archive of the 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:
> 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/
4) Hardwired as(address_space) to unw_local_addr_space in
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]