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
>>
>
>
_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel
