All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	nd@arm.com, Stefano Stabellini <stefanos@xilinx.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v4 2/2] xen: use SYMBOL when required
Date: Wed, 09 Jan 2019 02:39:14 -0700	[thread overview]
Message-ID: <5C35C142020000780020BBAC@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1901080953330.800@sstabellini-ThinkPad-X260>

>>> On 08.01.19 at 19:08, <sstabellini@kernel.org> wrote:
> On Tue, 8 Jan 2019, Stefano Stabellini wrote:
>> So, this is what I am going to do: I'll send a series update according
>> to your suggestion, with SYMBOL returning the native pointer type. As I
>> wrote earlier, although weaker, it is still an improvement from my point
>> of view.
> 
> There is a problem with this though I didn't foresee :-(
> 
> The native type of _start is not char* -- it is char[]. So I cannot
> actually return the native type from SYMBOL because I cannot cast to
> (char[]). I didn't notice it until I actually tried it.
> 
> See the implementation of RELOC_HIDE:
> 
>   #define RELOC_HIDE(ptr, off)                    \
>     ({ unsigned long __ptr;                       \
>       __asm__ ("" : "=r"(__ptr) : "0"(ptr));      \
>       (typeof(ptr)) (__ptr + (off)); })
> 
> It casts to the type at the end, the error is:
> 
>   error: cast specifies array type
>        (typeof(ptr)) (__ptr + (off)); })
> 
> We have a few options:
> 
> 1) use unsigned long as in this version of the series (the Linux kernel
> also uses this technique)
> Sorry if I insist, it is still the best I think :-)
> 
> 2) casts the parameters of SYMBOL to the corresponding pointer type
> For instance:
>   SYMBOL((char *)_start)
>   SYMBOL((struct alt_instr *)__alt_instructions_end)
> This works, but it is ugly, I would say it makes the code worse than
> option 1)
> 
> 2) always return void* from SYMBOL
> I don't think it is a good idea to use void* as a workaround here
> 
> 3) pass the desired return type to SYMBOL
> For instance:
>   SYMBOL(_start, char *)
>   SYMBOL(__alt_instructions_end, struct alt_instr *)
> Then SYMBOL would automatically cast the return type to char * and
> struct alt_instr * according to the second parameter.
> 
> Do you have any other suggestions?

4) 

#define RELOC_HIDE(ptr, off)                    \
    ({ unsigned long ptr_;                       \
      __asm__ ("" : "=r"(ptr_) : "0" (ptr));      \
      (typeof(*(ptr)) *) (ptr_ + (off)); })

or, if not suitable for RELOC_HIDE() itself, clone the macro into one
that fits SYMBOL()'s needs.

Jan



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

  parent reply	other threads:[~2019-01-09  9:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-12 23:06 [PATCH v4 0/2] misc safety certification fixes Stefano Stabellini
2018-11-12 23:06 ` [PATCH v4 1/2] xen: introduce SYMBOL Stefano Stabellini
2018-11-12 23:06 ` [PATCH v4 2/2] xen: use SYMBOL when required Stefano Stabellini
2018-11-13 12:56   ` Jan Beulich
2018-11-13 13:17     ` Julien Grall
2018-11-13 13:27       ` Jan Beulich
2018-11-13 22:02         ` Stefano Stabellini
2018-11-14  7:44           ` Jan Beulich
2019-01-02 18:20             ` Stefano Stabellini
2019-01-04  8:48               ` Jan Beulich
2019-01-04 17:05                 ` Stefano Stabellini
2019-01-07  7:39                   ` Jan Beulich
2019-01-07 18:29                     ` Stefano Stabellini
2019-01-08  8:03                       ` Jan Beulich
2019-01-08 17:36                         ` Stefano Stabellini
2019-01-08 18:08                           ` Stefano Stabellini
2019-01-08 18:43                             ` Julien Grall
2019-01-09  9:39                             ` Jan Beulich [this message]
2019-01-09 23:50                               ` Stefano Stabellini
2019-01-02 18:20     ` Stefano Stabellini
2019-01-02 21:04       ` Stefano Stabellini
2019-01-03 19:22         ` Stefano Stabellini
2018-12-20 17:26 ` [PATCH v4 0/2] misc safety certification fixes Julien Grall
2018-12-21  9:27   ` Jan Beulich
2018-12-21 10:34     ` Julien Grall
2018-12-21 17:15       ` Stefano Stabellini

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=5C35C142020000780020BBAC@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=julien.grall@arm.com \
    --cc=nd@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=stefanos@xilinx.com \
    --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.