All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.cz>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>
Subject: Re: [PATCH v4 19/27] x86: assembly, make some functions local
Date: Wed, 25 Oct 2017 16:18:31 +0200	[thread overview]
Message-ID: <f70a8042-463d-09c8-65f9-9d07f71b84a2__16998.2218220413$1508941176$gmane$org@suse.cz> (raw)
In-Reply-To: <CAKv+Gu9S0w0EUvruDjruR+hJ0B2QU_do1GknV83C8CgLTp8T2Q@mail.gmail.com>

On 10/06/2017, 04:01 PM, Ard Biesheuvel wrote:
> On 6 October 2017 at 13:53, Jiri Slaby <jslaby@suse.cz> wrote:
>> On 10/04/2017, 09:33 AM, Ard Biesheuvel wrote:
>>> In arm64, we use ENTRY/ENDPROC for functions with external linkage,
>>> and the bare symbol name/ENDPROC for functions with local linkage. I
>>> guess we could add ENDOBJECT if we wanted to, but we never really felt
>>> the need.
>>
>> Yes and this is exactly the reason for the new macros. Now, it's a
>> complete mess. One arch does this, another does that. And we are in a
>> state to have reliable stacktraces, let objtool check functions, let
>> objtool generate annotations (e.g. for ORC unwinder), etc.
>>
> 
> You are implying that ENTRY/ENDPROC and 'bare symbol name'/ENDPROC
> prevent you from doing any of this, but this is simply not true.

If I understand correctly, you have not read the discussion behind the
link I sent you... So in sum:
Initially, I only used the current ENTRY/ENDPROC approach and augmented
it to fix up the mess in x86. But it was concluded that these old macros
are terrible and we rather want to avoid them. It was especially the bad
naming of these old macros. So we discussed what the new naming scheme
could be and this is what we ended up with.

>> Without knowing what is start, where is its end, what is function, what
>> is object (data) etc., it can barely check or even generate anything
>> automatically. Not speaking about impaired macros like your name/ENDPROC
>> above.
>>
> 
> What is the problem with impaired macros?

Obviously that they are impaired. That is the tools do not know where to
stop with reading of code or data.

This is quite usual:

foo:
  mov data,a
  call bar
  ret

data: .string "hello"

This makes the tools to choke on the data while thinking it is still code.

> So what is preventing people from using these new macros in the wrong way?

The tools. It is quite easy to check this during build by a linker and I
have such a patch here. It was not yet concluded (I think) whether we
are going to check this via objtool or by something like my patch.
Noteworthy, objtool can check much more in this respect, obviously.

thanks,
-- 
js
suse labs

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2017-10-25 14:18 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02  9:12 [PATCH v4 01/27] linkage: new macros for assembler symbols Jiri Slaby
2017-10-02  9:12 ` Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 02/27] x86: assembly, use DATA_SIMPLE for data Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 03/27] x86: assembly, annotate relocate_kernel Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 04/27] x86: entry, annotate THUNKs Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 05/27] x86: assembly, annotate local pseudo-functions Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 06/27] x86: crypto, annotate local functions Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 07/27] x86: boot, " Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 08/27] x86: assembly, annotate aliases Jiri Slaby
2017-10-02  9:12   ` Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 09/27] x86: entry, annotate interrupt symbols properly Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 10/27] x86: head, annotate data appropriatelly Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 11/27] x86: boot, " Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 12/27] x86: um, " Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 13/27] x86: xen-pvh, " Jiri Slaby
2017-10-02  9:12   ` Jiri Slaby
2017-10-02 16:49   ` Boris Ostrovsky
2017-10-02 16:49   ` Boris Ostrovsky
2017-10-02  9:12 ` [PATCH v4 14/27] x86: purgatory, start using annotations Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 15/27] x86: assembly, do not annotate functions by GLOBAL Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 16/27] x86: assembly, use SYM_CODE_INNER_LABEL_NOALIGN instead of GLOBAL Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 17/27] x86: realmode, use SYM_DATA_* " Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 18/27] x86: assembly, remove GLOBAL macro Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 19/27] x86: assembly, make some functions local Jiri Slaby
2017-10-02  9:12   ` Jiri Slaby
2017-10-02 12:48   ` Ard Biesheuvel
2017-10-02 12:48     ` Ard Biesheuvel
2017-10-04  7:22     ` Jiri Slaby
2017-10-04  7:22     ` Jiri Slaby
2017-10-04  7:22       ` Jiri Slaby
2017-10-04  7:33       ` Ard Biesheuvel
2017-10-04  7:33       ` Ard Biesheuvel
2017-10-06 12:53         ` Jiri Slaby
2017-10-06 12:53         ` Jiri Slaby
2017-10-06 12:53           ` Jiri Slaby
2017-10-06 13:21           ` Mark Rutland
2017-10-06 13:21           ` Mark Rutland
2017-10-06 13:21             ` Mark Rutland
2017-10-25 14:21             ` Jiri Slaby
2017-10-25 14:21               ` Jiri Slaby
2017-10-25 14:46               ` Mark Rutland
2017-10-25 14:46                 ` Mark Rutland
2017-10-25 14:46               ` Mark Rutland
2017-10-25 14:21             ` Jiri Slaby
2017-10-06 14:01           ` Ard Biesheuvel
2017-10-06 14:01           ` Ard Biesheuvel
2017-10-06 14:01             ` Ard Biesheuvel
2017-10-25 14:18             ` Jiri Slaby
2017-10-25 14:18             ` Jiri Slaby [this message]
2017-10-02 12:48   ` Ard Biesheuvel
2017-10-02  9:12 ` [PATCH v4 20/27] x86: ftrace, mark function_hook as function Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 21/27] x86_64: assembly, add ENDs to some functions and relabel with SYM_CODE_* Jiri Slaby
2017-10-02  9:12   ` Jiri Slaby
2017-10-02 16:59   ` Boris Ostrovsky
2017-10-02 16:59   ` Boris Ostrovsky
2017-10-02  9:12 ` [PATCH v4 22/27] x86_64: assembly, change all ENTRY+END to SYM_CODE_* Jiri Slaby
2017-10-02 18:13   ` Boris Ostrovsky
2017-10-02 18:13   ` Boris Ostrovsky
2017-10-02  9:12 ` Jiri Slaby
     [not found] ` <20171002091246.28432-1-jslaby-AlSwsSmVLrQ@public.gmane.org>
2017-10-02  9:12   ` [PATCH v4 23/27] x86_64: assembly, change all ENTRY+ENDPROC to SYM_FUNC_* Jiri Slaby
2017-10-02  9:12     ` Jiri Slaby
2017-10-02 12:30     ` Rafael J. Wysocki
2017-10-02 12:30     ` Rafael J. Wysocki
2017-10-02 18:16     ` Boris Ostrovsky
2017-10-02 18:16     ` Boris Ostrovsky
2017-10-02  9:12 ` Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 24/27] x86_32: assembly, add ENDs to some functions and relabel with SYM_CODE_* Jiri Slaby
2017-10-02  9:12 ` Jiri Slaby
2017-10-02 18:16   ` Boris Ostrovsky
2017-10-02 18:16   ` Boris Ostrovsky
2017-10-03  0:26   ` Rafael J. Wysocki
2017-10-03  0:26   ` Rafael J. Wysocki
2017-10-02  9:12 ` [PATCH v4 25/27] x86_32: assembly, change all ENTRY+END to SYM_CODE_* Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 26/27] x86_32: assembly, change all ENTRY+ENDPROC to SYM_FUNC_* Jiri Slaby
2017-10-02  9:12 ` [PATCH v4 27/27] x86: assembly, replace WEAK uses Jiri Slaby
2017-10-06 15:23 ` [PATCH v4 01/27] linkage: new macros for assembler symbols Josh Poimboeuf
2017-10-25 14:20   ` Jiri Slaby
2017-10-25 14:20   ` Jiri Slaby
2017-10-06 15:23 ` Josh Poimboeuf

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='f70a8042-463d-09c8-65f9-9d07f71b84a2__16998.2218220413$1508941176$gmane$org@suse.cz' \
    --to=jslaby@suse.cz \
    --cc=ard.biesheuvel@linaro.org \
    --cc=hpa@zytor.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matt@codeblueprint.co.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.