[parisc-linux] PA-Linux version of libunwind

[parisc-linux] PA-Linux version of libunwind

[David Mosberger]

Hi,

I have started to add PA-Linux support to Libunwind.  At the moment,
I'm only targeting DWARF2 unwind info (not the SOM-style PARISC
unwind-records) and not everything is implemented/working yet.  Even
so, many tests in the built-in test-suite already succeed.  Thus, I
think that even in this early state, others may have some use for it
so I thought it might be a good idea to mention it on this list (and
of course, bug-fixes/contributions are always welcome, too ;-).

At the moment, the PA Linux support is available only via the
bitkeeper repository at:

	bk://unwind.bkbits.net/libunwind/

If you want to play with this, just be sure to read the README.

A brief blurb on what libunwind is about is attached below.  For more
details, see:

  http://www.hpl.hp.com/research/linux/libunwind/intro.php4

The web-site also hosts the man-pages for the libunwind API and has
info on the libunwind mailing list.

Enjoy,

	--david

--
Libunwind is a portable and efficient C API to enable call-chain
introspection.  Some examples for what it can be used include:

    exception handling
        The libunwind API makes it trivial to implement the
        stack-manipulation aspects of exception handling.

    debuggers
        The libunwind API makes it trivial for debuggers to generate
        the call-chain (backtrace) of the threads in a running
        program.

    introspection
        It is often useful for a running thread to determine its
        call-chain. For example, this is useful to display error
        messages (to show how the error came about) and for
        performance monitoring/analysis.

    efficient setjmp()
        With libunwind, it is possible to implement an extremely
        efficient version of setjmp(). Effectively, the only context
        that needs to be saved consists of the stack-pointer(s).
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA-Linux version of libunwind

[Grant Grundler]

On Sat, Dec 04, 2004 at 05:19:47PM -0800, David Mosberger wrote:
> Hi,
> 
> I have started to add PA-Linux support to Libunwind.

David,
Awesome!

> At the moment,
> I'm only targeting DWARF2 unwind info (not the SOM-style PARISC
> unwind-records) and not everything is implemented/working yet.

SOM is dead AFAIK. Only HPUX 32-bit uses SOM for anything.
I'm not sure where DWARF fits into the gcc releases but maybe
someone could remind me.

>   Even
> so, many tests in the built-in test-suite already succeed.  Thus, I
> think that even in this early state, others may have some use for it
> so I thought it might be a good idea to mention it on this list (and
> of course, bug-fixes/contributions are always welcome, too ;-).

:^)

> At the moment, the PA Linux support is available only via the
> bitkeeper repository at:
> 
> 	bk://unwind.bkbits.net/libunwind/

This worked for me:
# bk clone http://unwind.bkbits.net/libunwind/
# cd libunwind
# bk -r co -q

BTW, bitkeeper client is available for parisc-linux from bitkeeper.com.
I have it installed on most of my machines.

thanks again,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA-Linux version of libunwind

[John David Anglin]

> > I'm only targeting DWARF2 unwind info (not the SOM-style PARISC
> > unwind-records) and not everything is implemented/working yet.
> 
> SOM is dead AFAIK. Only HPUX 32-bit uses SOM for anything.
> I'm not sure where DWARF fits into the gcc releases but maybe
> someone could remind me.

While only HP-UX 32-bit uses the SOM object format, parisc-linux
currently generates SOM-style unwind records generated from .callinfo
and other assembler statements.  At the moment, gdb uses the SOM-style
unwind records.

DWARF2 exception support has been available since GCC 3.3 but
the default exception model is still SJLJ.  SJLJ and DWARF2
can't be supported together in the same GCC build.  At the
moment, DWARF2 unwind info is generated only when using GCC
built with DWARF2 exception support, and when one of the following
GCC options is specified: -fexceptions, -funwind_tables or
-fasynchonous_unwind_tables.  You get -fexceptions when the
g++ driver is used, and possibly also with gcj.  Thus, some
migration to the new DWARF2 support is needed to take full
advantage of David's new library.

I must say I welcome David's new library.  Unwinding in gdb
has never been reliable with the SOM-style unwind records.
Some code reading is needed, etc.  The new library will make
it easy for applications to unwind on exceptions and print
backtraces when an internal problem occurs.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA-Linux version of libunwind

[David Mosberger]

Hi John,

>>>>> On Sat, 4 Dec 2004 22:04:45 -0500 (EST), "John David Anglin" <dave@hiauly1.hia.nrc.ca> said:

  John> While only HP-UX 32-bit uses the SOM object format,
  John> parisc-linux currently generates SOM-style unwind records
  John> generated from .callinfo and other assembler statements.  At
  John> the moment, gdb uses the SOM-style unwind records.

Yes, that's why I mentioned SOM.  I already discussed the issue
briefly with Randolph.  We _could_ put PARISC Unwind Record support
into libunwind, but it's not clear whether it's worth the trouble.
The big issue is that under Linux, the only way to get to the PARISC
Unwind Records seems to be via the ELF file and that's not (directly)
accessible from within a running process.  That's not a problem for
gdb, of course, but in effect, use of PARISC Unwind Record would be
limited to what libunwind calls remote unwinding.  It may make more
sense to leave the PARISC Unwind Record support in gdb and just
declare support for those Unwind records as deprecated.

  John> I must say I welcome David's new library.  Unwinding in gdb
  John> has never been reliable with the SOM-style unwind records.
  John> Some code reading is needed, etc.  The new library will make
  John> it easy for applications to unwind on exceptions and print
  John> backtraces when an internal problem occurs.

gdb already has a DWARF2 unwinder and at this point I'm unsure whether
it's better to enable PARISC support for that unwinder or for
libunwind.  Whatever makes the most sense is fine with me.  However, I
do hope that having libunwind available on more (DWARF2) platforms
will get people away from constantly reinventing the wheel in regards
to unwinders.  As Randolph says, each unwinder tends to come with its
own set of limitations and bugs.  With the single source-tree provided
by libunwind, I hope to eliminate that problem.

	--david
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA-Linux version of libunwind

[David Mosberger]

>>>>> On Sun, 5 Dec 2004 01:16:40 -0800, Randolph Chung <randolph@tausq.org> said:

  Randolph> The kernel contains a primitive SOM unwind record-based
  Randolph> unwinder. That will also need to be redone if we decide to
  Randolph> go to dwarf2 only unwinding (but i guess David is working
  Randolph> towards that anyway).

Ugh, it's good you mention this!  Just a few days ago, I raised the
question of in-kernel unwind support for various Linux platforms.
Nobody expressed a clear-cut interest so far (I fear I asked on the
wrong mailing-list...).  It sounds like PARISC Linux would benefit
from having libunwind-support in the kernel?  I'm pretty sure Alpha
needs that too.  There are probably others that would want it, too.
So far, it looks like only SPARC and PPC{,64} don't need libunwind,
since the hardware/calling-convention squirrels away enough info in
the stack-frames to not need unwind-info.

  Randolph> One tricky thing though is that while generating SOM-style
  Randolph> unwind records for hand-written assembly is fairly
  Randolph> straightforward, generating dwarf2-unwind data is not
  Randolph> quite so easy... possibly we need to do some work to make
  Randolph> this somewhat easier to handle.

The cfi-directive support recently added to the binutils makes it
fairly straight-forward though.  Basically, you just need to annotate
the instructions that manipulate the stack-pointer and instructions
that save/restore a preserved register.

	--david
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA-Linux version of libunwind

[Grant Grundler]

On Sat, Dec 04, 2004 at 05:19:47PM -0800, David Mosberger wrote:
...
> At the moment, the PA Linux support is available only via the
> bitkeeper repository at:
> 
> 	bk://unwind.bkbits.net/libunwind/
> 
> If you want to play with this, just be sure to read the README.

I read the README and learned I should be using gcc 3.4.x (and
debian testing default is gcc-3.3.4).

But I ran into a different (trivial) problem during the build:
...
make[1]: Leaving directory `/home/src/libunwind/tests'
Making all in doc
make[1]: Entering directory `/home/src/libunwind/doc'
latex2man -t ./libunwind.trans libunwind.tex libunwind.man
make[1]: latex2man: Command not found
make[1]: *** [libunwind.man] Error 127
make[1]: Leaving directory `/home/src/libunwind/doc'
make: *** [all-recursive] Error 1

apt-cache search latex2man and packages.debian.org didn't help.
Anyone have a clue which package latex2man is in?

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA-Linux version of libunwind

[David Mosberger]

>>>>> On Sat, 4 Dec 2004 22:09:17 -0700, Grant Grundler <grundler@parisc-linux.org> said:

  Grant> On Sat, Dec 04, 2004 at 05:19:47PM -0800, David Mosberger
  Grant> wrote: ...
  >> At the moment, the PA Linux support is available only via the
  >> bitkeeper repository at:
  >> 
  >> bk://unwind.bkbits.net/libunwind/
  >> 
  >> If you want to play with this, just be sure to read the README.

  Grant> I read the README and learned I should be using gcc 3.4.x
  Grant> (and debian testing default is gcc-3.3.4).

  Grant> But I ran into a different (trivial) problem during the
  Grant> build: ...  make[1]: Leaving directory
  Grant> `/home/src/libunwind/tests' Making all in doc make[1]:
  Grant> Entering directory `/home/src/libunwind/doc' latex2man -t
  Grant> ./libunwind.trans libunwind.tex libunwind.man make[1]:
  Grant> latex2man: Command not found make[1]: *** [libunwind.man]
  Grant> Error 127 make[1]: Leaving directory
  Grant> `/home/src/libunwind/doc' make: *** [all-recursive] Error 1

  Grant> apt-cache search latex2man and packages.debian.org didn't
  Grant> help.  Anyone have a clue which package latex2man is in?

If the time-stamps are correct, it shouldn't even try to rebuild the
man files, but you can work around the lack of latex2man with

	$ make L2M=cp

  --david
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA-Linux version of libunwind

[Grant Grundler]

On Sat, Dec 04, 2004 at 09:15:00PM -0800, David Mosberger wrote:
> If the time-stamps are correct, it shouldn't even try to rebuild the
> man files,

I suspect the "bk -r -co -q" puts a current timestamp on the files.

>  but you can work around the lack of latex2man with
> 
> 	$ make L2M=cp

yep - that works too.

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux