[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?
From: |
Doug Moore |
Subject: |
Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it? |
Date: |
Thu, 30 Mar 2017 15:58:03 -0500 |
It’s not clear to me how to push this to you via GitHub. So, instead, I’ve
attached a patch to add unw_local_init_signal to the API, to solve my problem.
Please consider it.
Doug
add_local_init_signal.patch
Description: Binary data
> On Mar 30, 2017, at 12:00 PM, Doug Moore <address@hidden> wrote:
>
> Documentation has to change anyway, since the unw_init_local docs are
> currently broken.
>
> Decrementing the ip for my case (using unw_set_reg) gets me through a few
> unw_step calls successfully, then crashes the program.
>
> But I can't win this fight, so I'll quit.
>
> Maybe I can get a new cursor init function added to the API. Would the
> powers that be accept a change that added unw_init_local_signal, which is
> just like unw_init_local except that it doesn't set use_prev_instr? If not
> that name, the same thing by some other name? I can post that change pretty
> quickly, if only someone will consider it.
>
> Doug
>
>
> Quoting Dave Watson <address@hidden>:
>
>> On 03/29/17 04:51 PM, Doug Moore wrote:
>>> Can’t we fix this whole problem by having getcontext subtract from the pc
>>> to start with, so that nobody ever has to decrement the pc on the first
>>> call to unw_step?
>>
>> That would assume that the ucontext is usually from a signal frame
>> (third argument from a sigaction handler), which is probably pretty
>> common. It would break anyone that grabbed it outside a handler using
>> getcontext() instead of unw_getcontext() though.
>>
>> The current documentation says:
>>
>> ```
>> On IA-64, unw_context_t has a layout that is compatible with that of
>> ucontext_t and such structures can be initialized with getcontext()
>> instead of unw_getcontext()
>> ```
>>
>> so it might be a somewhat interface breaking change.
>>
>> Conversely, for your use case you might just be able to bump the ip by
>> one in the ucontext before the first unw_step()?
>>
>>
>> !DSPAM:10223,58dd225839344861828991!
>
>
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, (continued)
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Doug Moore, 2017/03/26
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Dave Watson, 2017/03/27
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Dave Watson, 2017/03/27
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Doug Moore, 2017/03/27
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Dave Watson, 2017/03/29
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Doug Moore, 2017/03/29
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Doug Moore, 2017/03/29
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Doug Moore, 2017/03/29
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Dave Watson, 2017/03/30
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Doug Moore, 2017/03/30
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?,
Doug Moore <=
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Dave Watson, 2017/03/30
- Re: [Libunwind-devel] use_prev_instr breaking unwind - how to stop it?, Doug Moore, 2017/03/30