Re: About libunwind and dogtail

[Rick Moseley <rmoseley at redhat dot com>]

Wu Zhou wrote:
> Hello Andrew and all,
>
> We talked about libunwind and dogtail for ppc64 before. I am recently
> taking some look into these two. I would like to post my current
> understanding here for your review. If there are anything wrong or
> missing, please point out and correct me. Thanks a lot!
>
> For dogtail, it is writen in python, based on accessibility
> technology. It will use at-spi to communicate with the AT-supporting
> GNOME (or other GUI) application. From the point of theory/design, all
> of them are platform independent. But from the point of practice, all
> these package (GNOME, at-spi, pyspi, dogtail) are receving much less
> attention on ppc64 than on x86. So our point is that we need to test
> them on ppc64 and try to find how it works on this platform. We will
> aslo work with upstream package maintainers to fix exposed defects. Is
> my understanding right?
>
> About libunwind, there are some platform dependent feature. My
> understanding is that it initiated from ia64 platform and are now
> being ported to x86 platform. On ia64, it support local unwind, remote
> unwind (I guess this is what interests frysk most, right?), ptrace
> stop and resume, get proc/register information... In my opinion, quite
> some of these features are platform dependent. Do we need to port all
> these functionality to other platforms (x86, ppc64 or x86-64)? I run a
> make check on x86 platform, it reported 13 of 24 tests failed. There
> are some segmentation fault and also some failure of unw_step. So I
> guess libunwind is not very mature on x86 yet and not all features are
> ported to x86 too. My opinion is that we need only port what is needed
> by frysk first. So I have a quesiton here: in what way is libunwind
> expected to be used in frysk? I guess it surely includes different
> process unwind on the same machine. But will it includes remote
> process unwind on a different machine/target? Getting the answer for
> these is very helpful for us to focus on high-priority work item.
Yes, your information is correct about libunwind originating on the ia64
platform as HP engineers are doing the development there. According to
the README, the x86_64 "Works well." and the x86 status is "Works well,
but C library is missing some unwind-info." Also, according the README
several tests on x86 are expected to fail:

** Expected results on x86 Linux

The following tests are expected to fail on x86 Linux:

Gtest-bt (see http://sources.redhat.com/bugzilla/show_bug.cgi?id=595)
Ltest-bt (likewise)
Gtest-resume-sig (likewise)
Ltest-resume-sig (likewise)
Gtest-dyn1 (no dynamic unwind info support yet)
Ltest-dyn1 (no dynamic unwind info support yet)
test-setjmp (longjmp() not implemented yet)
run-check-namespace (no _Ux86_getcontext yet)

So, indeed, x86 tests are expected to fail and according to the README,
a lot of the same ones fail for x86_64.

The first major feature we are trying to implement for Frysk using
libunwind will be to get backtraces, so, if you want some focus on where
to place development resources, that is the initial area we will be
concentrating on. Remote debugging is definitely in our plans, but is
not our immediate goal. We want to get local debugging solid before
moving on to remote deugging. Any changes you make should be flexible
enough to be able to handle remote debugging in the future.

Hope this helps.

Rick

>
> Regards
> - Wu Zhou