Hi Andrew,

Yes, there is a possibility that I can work on this integration sooner
rather than later.  Let me see what I can do...

Regards,

 --david

On 1/18/07, Andrew Cagney <[EMAIL PROTECTED]> wrote:
David,

Would something sooner be possible, we have been waiting a while :-/  As
it is, frysk is being forced to carry round a significant number of
patches.  Btw, if it makes things easier you can also inspect the
changes by accessing frysk's repository using something like:

   cvs -d:pserver:[EMAIL PROTECTED]:/cvs/frysk co libunwind

Andrew

David Mosberger-Tang wrote:
> Not yet.  My plan is to get back to libunwind work after our house
> remodelling is finished (should be some time in March).  If there are
> urgent things that need addressing, let me know though.
>
> Regards,
>
>  --david
>
> On 1/10/07, Andrew Cagney <[EMAIL PROTECTED]> wrote:
>> David, Mike,
>>
>> thanks for reminding me; did we get a chance to go through that summary
>> set of patches for x86 and x86-64 from the frysk project (
>> http://sourceware.org/frysk ) that were posted. See:
>> http://lists.gnu.org/archive/html/libunwind-devel/2006-11/msg00003.html
>> It would be good to see these merged
>>
>> Andrew
>>
>> David Mosberger-Tang wrote:
>> > Corey,
>> >
>> > The HP-PA port of libunwind isn't terribly stable or even complete.
>> > Looking at x86, x86-64, or ia64 ports is probably a better idea.
>> >
>> >  --david
>> >
>> > On 1/9/07, Corey Ashford <[EMAIL PROTECTED]> wrote:
>> >> Hello,
>> >>
>> >> I'm currently working on a port of libunwind to the PowerPC and am
>> >> having trouble understanding some parts of the code in libunwind.
>> >>
>> >> In particular, I'm not sure of the right place to put the code to
>> update
>> >> c->dwarf.loc[UNW_TDEP_IP] during a call to unw_step().  The return
>> >> address register is getting updated correctly, but the IP address
>> is a
>> >> pseudo-dwarf register, and so the dwarf unwinding isn't doing that
>> part
>> >> of the logic.
>> >>
>> >> Where would be the best place to put the code that updates this
>> >> pseudo-register?
>> >>
>> >> On a related subject:
>> >>
>> >> In trying to figure this out, I was looking at the HPPA
>> implementation
>> >> and I see the following code in tdep_access_reg:
>> >>
>> >>    switch (reg)
>> >>      {
>> >>      case UNW_HPPA_IP:
>> >>        if (write)
>> >>          c->dwarf.ip = *valp; /* update the IP cache */
>> >>        if (c->dwarf.pi_valid && (*valp < c->dwarf.pi.start_ip ||
>> >>           *valp >= c->dwarf.pi.end_ip))
>> >>         c->dwarf.pi_valid = 0;  /* new IP outside of current proc */
>> >>        break;
>> >>       ...
>> >>      }
>> >>
>> >>    if ((unsigned) (reg - UNW_HPPA_GR) >= 32)  /**** SEE BELOW ****/
>> >>      return -UNW_EBADREG;
>> >>
>> >>    loc = c->dwarf.loc[reg];
>> >>
>> >>    if (write)
>> >>      return dwarf_put (&c->dwarf, loc, *valp);
>> >>    else
>> >>      return dwarf_get (&c->dwarf, loc, valp);
>> >> }
>> >>
>> >> Here's a problem, as I see it.  (UNW_TDEP_IP - UNW_HPPA_GR) == 64
>> which
>> >> is >= 32 and therefore an attempt to read the UNW_TDEP_IP register
>> will
>> >> result in returning -UNW_EBADREG.
>> >>
>> >> Is that right or am I missing something there?
>> >>
>> >> Thanks for your consideration,
>> >>
>> >> - Corey
>> >>
>> >> --
>> >> Corey Ashford
>> >> Software Engineer
>> >> IBM Linux Technology Center, Linux Toolchain
>> >> Beaverton, OR
>> >> 503-578-3507
>> >> [EMAIL PROTECTED]
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Libunwind-devel mailing list
>> >> [email protected]
>> >> http://lists.nongnu.org/mailman/listinfo/libunwind-devel
>> >>
>> >
>> >
>>
>>
>
>




--
Mosberger Consulting LLC, http://www.mosberger-consulting.com/


_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel

Reply via email to