From: Andy Lutomirski <luto@amacapital.net>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Tony Jones <tonyj@suse.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH, RFC] x86: also CFI-annotate certain inline asm()s
Date: Thu, 6 Nov 2014 09:00:28 -0800 [thread overview]
Message-ID: <CALCETrW5ze6jSv-_mhby=2k3eiq=juoZRgxX7AQA8Vuh0CEcTw@mail.gmail.com> (raw)
In-Reply-To: <545B5CFC0200007800045463@mail.emea.novell.com>
On Thu, Nov 6, 2014 at 2:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 05.11.14 at 18:23, <luto@amacapital.net> wrote:
>> On Wed, Nov 5, 2014 at 9:13 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>>> Andy Lutomirski <luto@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
next prev parent reply other threads:[~2014-11-06 17:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-04 9:24 [PATCH, RFC] x86: also CFI-annotate certain inline asm()s Jan Beulich
2014-11-04 19:40 ` Andy Lutomirski
2014-11-05 17:13 ` Jan Beulich
2014-11-05 17:23 ` Andy Lutomirski
2014-11-06 10:35 ` Jan Beulich
2014-11-06 17:00 ` Andy Lutomirski [this message]
2014-11-10 10:01 ` Ingo Molnar
[not found] ` <CA+55aFw9MV1n8T7_k5oftfY-sOu8s1ywKYM-3k4+PF022vv9ow@mail.gmail.com>
2014-11-10 18:10 ` Linus Torvalds
2014-11-11 7:52 ` Jan Beulich
2014-11-10 18:17 ` Ingo Molnar
2014-11-11 7:42 ` Jan Beulich
2014-11-12 20:36 ` Linus Torvalds
2014-11-13 7:49 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALCETrW5ze6jSv-_mhby=2k3eiq=juoZRgxX7AQA8Vuh0CEcTw@mail.gmail.com' \
--to=luto@amacapital.net \
--cc=JBeulich@suse.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=tonyj@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).