From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor
Date: Thu, 1 Mar 2012 10:27:02 +0000 [thread overview]
Message-ID: <20120301102702.GD2034@linaro.org> (raw)
In-Reply-To: <20120301101029.GB7363@n2100.arm.linux.org.uk>
On Thu, Mar 01, 2012 at 10:10:29AM +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 29, 2012 at 12:58:26PM +0000, Dave Martin wrote:
> > On Wed, Feb 29, 2012 at 09:56:02AM +0000, Ian Campbell wrote:
> > > On Wed, 2012-02-29 at 09:34 +0000, Dave Martin wrote:
> > > > On Tue, Feb 28, 2012 at 12:28:29PM +0000, Stefano Stabellini wrote:
> > >
> > > > > I don't have a very strong opinion on which register we should use, but
> > > > > I would like to avoid r7 if it is already actively used by gcc.
> > > >
> > > > But there is no framepointer for Thumb-2 code (?)
> > >
> > > Peter Maydell suggested there was:
> > > > r7 is (used by gcc as) the Thumb frame pointer; I don't know if this
> > > > makes it worth avoiding in this context.
> > >
> > > Sounds like it might be a gcc-ism, possibly a non-default option?
> > >
> > > Anyway, I think r12 will be fine for our purposes so the point is rather
> > > moot.
> >
> > Just had a chat with some tools guys -- apparently, when passing register
> > arguments to gcc inline asms there really isn't a guarantee that those
> > variables will be in the expected registers on entry to the inline asm.
>
> The best you can do is:
>
> register unsigned int foo asm("r7") = value;
>
> asm("blah %0" : : "r" (foo));
>
> and ensure that your assembly checks that %0 _is_ r7 and produces a build
> error if not. See the __asmeq() macro in asm/system.h to find out how to
> do that.
>
> This feature has been missing from ARM GCC for quite a long time - it's
> used extensively on x86 GCC, where they have one register class per
> register, so they can do stuff like:
>
> asm("blah %0" : : "a" (value));
>
> and be guaranteed that %0 will be eax.
>
> > If you need a specific register, this means that you must set up that
> > register explicitly inside the asm if you want a guarantee that the
> > code will work:
> >
> > asm volatile (
> > "movw r12, %[hvc_num]\n\t"
> > ...
> > "hvc #0"
> > :: [hvc_num] "i" (NUMBER) : "r12"
> > );
> >
> > Of course, if you need to set up more than about 5 or 6 registers in
> > this way, the doubled register footprint means that the compiler will
> > have to start spilling stuff to the stack.
>
> No it won't - it will barf instead - think about it. If you're clobbering
> r0 - r5, but need to pass in six values in registers, gcc can't use r0-r5
> for that, so it must use the remaining registers. It gets rather unhappy
> with that, and starts erroring out (iirc 'too many reloads' or some similar
> error.) I've been there.
You're right about that -- I didn't pursue my line of thought to the end,
there. I have see the behaviour you describe.
> If you want to do it that way, your only option is to store them to memory
> and pass the address of the block into the assembly, and reload them there.
> Which is extremely sucky and inefficient.
>
> Practically, the register variable plus asm() does seem to work, and seems
> to work for virtually all gcc versions out there (there have been the odd
> buggy version, but those bugs appear to get fixed.)
That is inconvenient for us, but it's a not a bug. The ability for asm
contraints to be able to gcc to put things in specific registers (as with
the gcc "abcd" constraints for i386) would be nice, but as you point out,
this capability is simply not supported by gcc right now for ARM -- the
compiler guys seem to be pretty opposed to it, so I can't say I anticiapte
this being supported in the near future.
So, where there's a compelling reason to inline these things, we can use
the existing techniques if we're alert to the risks. But in cases where
there isn't a compelling reason, aren't we just inviting fragility
unnecessarily?
Cheers
---Dave
next prev parent reply other threads:[~2012-03-01 10:27 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 17:47 [PATCH-WIP 00/13] xen/arm: receive Xen events and initialize xenbus Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor Stefano Stabellini
2012-02-27 16:27 ` Ian Campbell
2012-02-27 18:03 ` Dave Martin
2012-02-27 19:33 ` Ian Campbell
2012-02-28 10:20 ` Dave Martin
2012-02-28 10:48 ` Ian Campbell
2012-02-28 12:28 ` Stefano Stabellini
2012-02-29 9:34 ` Dave Martin
2012-02-29 9:56 ` Ian Campbell
2012-02-29 11:47 ` Dave Martin
2012-02-29 12:58 ` Dave Martin
2012-02-29 14:44 ` Ian Campbell
2012-03-01 9:35 ` Dave Martin
2012-03-01 10:12 ` Russell King - ARM Linux
2012-03-02 21:19 ` Nicolas Pitre
2012-02-29 14:52 ` Stefano Stabellini
2012-03-01 9:51 ` Dave Martin
2012-03-01 10:10 ` Russell King - ARM Linux
2012-03-01 10:27 ` Dave Martin [this message]
2012-03-01 10:35 ` Russell King - ARM Linux
2012-03-01 12:12 ` Stefano Stabellini
2012-03-02 21:15 ` Nicolas Pitre
2012-03-08 9:58 ` Richard Earnshaw
2012-03-08 12:17 ` Dave Martin
2012-03-08 17:21 ` Nicolas Pitre
2012-03-08 18:47 ` Richard Earnshaw
2012-03-09 15:58 ` Dave Martin
2012-03-09 16:20 ` Nicolas Pitre
2012-03-09 17:38 ` Richard Earnshaw
2012-02-27 21:05 ` Peter Maydell
2012-02-28 10:12 ` Ian Campbell
2012-02-27 17:53 ` Dave Martin
2012-02-27 19:48 ` Ian Campbell
2012-02-28 9:46 ` Dave Martin
2012-02-28 10:07 ` Ian Campbell
2012-02-28 12:21 ` Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 02/13] xen/arm: introduce privcmp, physdev_op and memory_op hypercalls Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 03/13] xen/arm: mmu.h and page.h related definitions Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 04/13] xen/arm: sync_bitops Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 05/13] xen/arm: empty implementation of grant_table arch specific functions Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 06/13] xen/arm: missing includes Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 07/13] xen/arm: receive xen events on arm Stefano Stabellini
2012-02-24 11:12 ` David Vrabel
2012-02-24 12:23 ` Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 08/13] xen/arm: fix arm xen guest handle definitions Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 09/13] xen/arm: shared_info and start_info Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 10/13] xen/arm: empty implementation of xen_remap_domain_mfn_range Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 11/13] xen/arm: Introduce xen_pfn_t for pfn and mfn types Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 12/13] xen/arm: compile and run xenbus Stefano Stabellini
2012-02-23 17:48 ` [PATCH-WIP 13/13] xen/arm: compile grant-table features events and xenbus, do not compile pci 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=20120301102702.GD2034@linaro.org \
--to=dave.martin@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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).