Re: [libunwind] unwinding through dynamically modified code?

[Todd L Miller]

> This looks wrong: the "when" field must be set to the index of the
> instruction it is describing.

        Just out of curiosity, why not just use which instruction in the
region it is?

> Not just superfluous, but actually illegal.  Libunwind would complain
> at the time this descriptor was interpreted (for performance-reasons,
> no checking is done at the time _U_dyn_register() is called).

        So what do I say about changing the GP?  Anything?

> Eh, r4-r7 are "preserved" registers.  If you save those, you'll need
> to add describe the saving instructions.

        Nope.  (Also skip SP and TP.)

> You'll need to open up a new region.  Assuming that the code matches
> _exactly_ as the code at the original location, you can use ALIAS
> to ensure that the unwinder will find the right unwind info.

        I think I asked this same question in the email I just sent to the
list, but: if I want to say the state is the same but the code is not, how
do I do that?

> If I understand you correctly, label_state and copy_state would be
> what you'd want to use here.

        Can I copy_state from static unwind information, is that the
effect of the zero-length ALIAS region you suggested earlier?  (That is,
should I ALIAS the intermediate region (where the state is the same as in
function from which I jumped to this code fragment), and let it extend
over the whole intermediate region, or label the initial state of the
second region (the one immediately after the initial ALIAS) and copy it?)

> Just for your info: the tests/test-ptrace program can single-step over
> a (region) of a program and unwind at each step.

        Regretably, I can't yet save the changes I'm making to the remote
process, so I won't be able to use it, but I'll keep the technique in
mind.

> Thanks,

        No, thank you. :)

- Todd Miller