On Thu, Nov 6, 2014 at 2:35 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 05.11.14 at 18:23, <l...@amacapital.net> wrote:
>> On Wed, Nov 5, 2014 at 9:13 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>>>>> Andy Lutomirski <l...@amacapital.net> 11/04/14 8:40 PM >>>
>>>>On 11/04/2014 01:24 AM, Jan Beulich wrote:
>>>>> The main obstacle to having done this long ago was the need to
>>>>> determine whether annotations are needed in the first place: They need
>>>>> to be avoided when a frame pointer got set up. Since I can't see a way
>>>>> to determine this before the compilation phase, this is being achieved
>>>>> by inspecting the memory address generated by the compiler in an
>>>>> interposed assembler macro. Of course this isn't really nice code, and
>>>>> this the main reason I'm posting this as RFC only at this point (with
>>>>> the hope that maybe someone has an idea of how to achieve the same
>>>>> thing in a more elegant way).
>>>>
>>>>Ask binutils for help?
>>>
>>> Binutils know as little about the code the compiler generated as we do.
>>
>> Could binutils add a
>> .cfi_adjust_cfa_offset_if_the_cfa_depends_on_sp_right_now directive?
>> IIUC, the issue is that, when you push, you don't want the canonical
>> frame address to change as a result, but you just changed the stack
>> pointer, so if the CFA is computed as an offset from the stack pointer
>> in the current context, that offset needs to change.
>
> While that's theoretically doable, I don't think this would be a
> reasonable approach.
>
I'll defer to your judgment about this. You clearly know a lot more
about cfi than I do :)
That being said, I've occasionally wanted the ability to do things
like this in userspace code, so maybe it wouldn't be a terrible
feature request.
>> Alternatively, is there any sane way to get the inline asm to act as
>> though it creates an entirely new frame? It would have CFA == rsp
>> initially (or rsp + 8 or whatever -- I can never keep track of what
>> the CFA is actually supposed to point to) and unwind instructions that
>> tell the unwinder that the caller pc is at a known address instead of
>> being stuck in the stack frame?
>
> No, that can't work: You'd have to
> - end the previous function (from the CFI engine's pov)
> - start a new function
> - do what you suggest above
> - end the "nested" function
> - start a continuation function for the subsequent compiler
> generated code
> - magically know the state of things at the point the original
> function got (artificially) ended
Fair enough. Empirically, sticking this in the middle of a function
doesn't work:
.cfi_remember_state
.cfi_endproc
.cfi_startproc
.cfi_restore_state
Oh, well.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
