From: Jiri Slaby <jslaby@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com,
x86@kernel.org, linux-kernel@vger.kernel.org,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Juergen Gross <jgross@suse.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 04/29] x86: assembly, use ENDPROC for functions
Date: Fri, 12 May 2017 09:53:48 +0200 [thread overview]
Message-ID: <4c3b765e-483a-4d9b-c451-6eccc02403f3@suse.cz> (raw)
In-Reply-To: <20170426014217.hshjlweqsimaumuy@treble>
On 04/26/2017, 03:42 AM, Josh Poimboeuf wrote:
>> @@ -323,7 +323,7 @@ ENTRY(resume_userspace)
>> movl %esp, %eax
>> call prepare_exit_to_usermode
>> jmp restore_all
>> -END(ret_from_exception)
>> +ENDPROC(ret_from_exception)
>
> What exactly is the motivation of this patch? It would be good to
> describe that in the commit message.
>
> Is the point to allow objtool to generate CFI for it? If so, I don't
> really see how that would work. Today, objtool considers ENDPROC to
> annotate a *callable* function which conforms to the C calling ABI and
> can be called by another function. The stack is in a known state at
> function entry, and so the CFI (or frame pointer info) can be reliably
> determined.
Ugh, I haven't checked this in 100 % of cases, but this looks pretty
fragile to me. From reading the code, the use of END or ENDPROC is
rather random -- depending on mood and who wrote the code.
> But entry code is different. In most cases, the global symbols aren't
> actually called, and they don't follow any conventions. The code is
> spaghetti-esque, with HW handlers and jumps everywhere. The state of
> the stack at symbol entry varies per "function". That's why objtool
> ignores these files.
Unfortunately, this is true.
> For special cases (like entry code), I was thinking we'd need manual CFI
> annotations, like we had before. Or maybe there's another way, like
> some new macros which tell objtool about the HW entry points and the
> state of the registers there.
>
> But I'm having trouble seeing how marking these code snippets with
> ENTRY/ENDPROC would help objtool make any sense of the code and where
> things are on the stack.
Ok, my intention was to have every line of assembly code in between of
FUNC_START/FUNC_END. That way, every rsp related push/pop/sub/add can be
annotated very easily. For the C-like functions this is all what needs
to be done.
Then there is the spaghetti code. And I was thinking about manual
annotations like:
# skip the frame pointer checking between START+END here
OBJTOOL(SKIP_CHECKING)
# this fn has unusual frame (like interrupts have),
and you can find return RIP stored at fp + 0x20
OBJTOOL(RIP_IS_AT, 0x20)
# put this raw CFI for this location into eh_frame
OBJTOOL(RAW_CFI, 0x00, 0x00, 0x00)
Similarly, I have OBJTOOL(START_FUNC) and OBJTOOL(END_FUNC) emitted with
each FUNC_START/FUNC_END. So far, when manually expanded for simplicity,
it looks like this:
#define OBJTOOL_START_FUNC \
.pushsection .discard.asmfunctions ASM_NL \
.long 0xfd111111 ASM_NL \
.long 1f - . ASM_NL \
.popsection ASM_NL \
1:
#define OBJTOOL_END_FUNC \
.pushsection .discard.asmfunctions ASM_NL \
.long 0xfe111111 ASM_NL \
.long 1f - . ASM_NL \
.popsection ASM_NL \
1:
0xfd111111, 0xfe111111 are "opcodes" for objtool meaning
START_FUNC/END_FUNC. Similar would be SKIP_CHECKING, RIP_IS_AT, and
RAW_CFI from the above.
So on the objtool side, it looks like:
switch (data->magic) {
case 0xfd111111:
pc_begin = rela->addend;
break;
case 0xfe111111:
ret = dwarf_annotate_func(dwarf, rela->sym->sec,
pc_begin, rela->addend - pc_begin);
if (ret < 0)
return -1;
break;
So this was my idea -- having all code marked as function and manually
annotate those which are different.
thanks,
--
js
suse labs
next prev parent reply other threads:[~2017-05-12 7:53 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-21 14:12 [PATCH v3 01/29] x86: boot/copy, remove unused functions Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 02/29] x86_32: boot, extract efi_pe_entry from startup_32 Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 03/29] x86_64: boot, extract efi_pe_entry from startup_64 Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 04/29] x86: assembly, use ENDPROC for functions Jiri Slaby
2017-04-26 1:42 ` Josh Poimboeuf
2017-05-12 7:53 ` Jiri Slaby [this message]
2017-05-12 22:15 ` Josh Poimboeuf
2017-05-17 13:23 ` Jiri Slaby
2017-05-19 9:17 ` Jiri Slaby
2017-05-19 19:50 ` Josh Poimboeuf
2017-04-21 14:12 ` [PATCH v3 05/29] x86: assembly, add ENDPROC to functions Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 06/29] x86: assembly, annotate functions by ENTRY, not GLOBAL Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 07/29] x86: bpf_jit, use ENTRY+ENDPROC Jiri Slaby
2017-04-21 19:32 ` Alexei Starovoitov
2017-04-24 6:45 ` Jiri Slaby
2017-04-24 14:41 ` David Miller
2017-04-24 14:52 ` Jiri Slaby
2017-04-24 15:08 ` David Miller
2017-04-24 15:41 ` Jiri Slaby
2017-04-24 15:51 ` David Miller
2017-04-24 15:53 ` Jiri Slaby
2017-04-24 15:55 ` Ingo Molnar
2017-04-24 16:02 ` Jiri Slaby
2017-04-24 16:40 ` Ingo Molnar
2017-04-24 16:47 ` Alexei Starovoitov
2017-04-24 17:51 ` Jiri Slaby
2017-04-24 18:24 ` David Miller
2017-04-25 14:41 ` Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 08/29] linkage: new macros for assembler symbols Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 09/29] x86: assembly, use DATA_SIMPLE for data Jiri Slaby
2017-04-27 11:53 ` Pavel Machek
2017-04-27 12:30 ` Jiri Slaby
2017-04-27 12:43 ` Pavel Machek
2017-04-21 14:12 ` [PATCH v3 10/29] x86: assembly, annotate relocate_kernel Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 11/29] x86: entry, annotate THUNKs Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 12/29] x86: assembly, annotate local functions Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 13/29] x86: crypto, " Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 14/29] x86: boot, " Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 15/29] x86: assembly, annotate aliases Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 16/29] x86: entry, annotate interrupt symbols properly Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 17/29] x86: head, annotate data appropriatelly Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 18/29] x86: boot, " Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 19/29] x86: um, " Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 20/29] x86: xen-pvh, " Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 21/29] x86: purgatory, start using annotations Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 22/29] x86: assembly, use SYM_FUNC_INNER_LABEL instead of GLOBAL Jiri Slaby
2017-04-21 14:12 ` [PATCH v3 23/29] x86: realmode, use SYM_DATA_* " Jiri Slaby
2017-04-21 14:13 ` [PATCH v3 24/29] x86: assembly, remove GLOBAL macro Jiri Slaby
2017-04-21 14:13 ` [PATCH v3 25/29] x86: assembly, make some functions local Jiri Slaby
2017-04-21 14:13 ` [PATCH v3 26/29] x86_64: assembly, change all ENTRY to SYM_FUNC_START Jiri Slaby
2017-04-21 14:13 ` [PATCH v3 27/29] x86_32: " Jiri Slaby
2017-04-21 14:13 ` [PATCH v3 28/29] x86_32: lguest, use SYM_ENTRY Jiri Slaby
2017-04-21 14:13 ` [PATCH v3 29/29] x86: assembly, replace WEAK uses Jiri Slaby
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=4c3b765e-483a-4d9b-c451-6eccc02403f3@suse.cz \
--to=jslaby@suse.cz \
--cc=boris.ostrovsky@oracle.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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).