libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libunwind] unwinding through dynamically modified code?


From: Todd L Miller
Subject: Re: [libunwind] unwinding through dynamically modified code?
Date: Wed, 24 Mar 2004 00:14:00 -0600 (CST)

>   Todd> code are the predicate registers (using UNW_DYN_SAVE_REG w/
>   Todd> UNW_IA64_PR), ar.pfs (w/ UNW_IA64_AR_PFS), r1 (w/ UNW_IA64_GR
>   Todd> + 1) and r12 (w/ UNW_IA64_GR + 12).
>
> Close, but not quite.  The unwinder needs to know about:

        So the unwinder does _not_ want/need to know about the predicate
registers and ar.pfs?  (IIRC, some of the predicate registers are
preserved; I can't remember about ar.pfs; it may be a 'special' register.)

> The global-pointer (r1/gp) is a special case: it can be looked up via
> the instruction-pointer, so there is no need to describe it explicitly
> via unwind info.

        That is to say that I should not have a _U_dyn_op_save_reg() for
r1?  (Even though I preserve it.)

> If a save-location becomes invalid for any other reason, you'd have to
> describe that, of course, but in general, it would be better to follow
> the convention of keeping save-locations live.

        OK.  They never become invalid, but ... ah, if they never become
invalid, then libunwind can always find them there, even if they return to
their original locations.

> BTW: such things are better described in the Software Convention &
> Runtime Architecture guide.

        Apparently you see more in it than I do. :)


        Anyway, I will try to post a code fragment and the associated
libunwind calls tommorow, and then we can see how much of all this I've
actually absorbed.

- Todd Miller


reply via email to

[Prev in Thread] Current Thread [Next in Thread]