Re: Ubuntu-based image for use with foundation model

On 27/11/13 15:07, Christopher Covington wrote: > Hi Ryan, > > On 11/27/2013 01:49 AM, Ryan Harkin wrote: >> On 26 November 2013 21:51, Michael Hudson-Doyle > > wrote: >> >> Hi all, >> >> Do we have, or do we have plans for, an image that's based on Ubuntu

Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor

letter scheme to map to actual > registers. > > > Nicolas > While it is technically possible, it is likely to end up hurting overall compiler performance as we'll then have to define the machine as having small register classes. -- Richard Earnshaw E

Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor

On 08/03/12 17:21, Nicolas Pitre wrote: > On Thu, 8 Mar 2012, Richard Earnshaw wrote: > >> On 02/03/12 21:15, Nicolas Pitre wrote: >>> So, to me, the gcc documentation is perfectly clear on this topic. >>> there really _is_ a guarantee that those asm marked variabl

Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor

On 02/03/12 21:15, Nicolas Pitre wrote: > [ coming back from vacation and trying to catch up ] > > On Wed, 29 Feb 2012, Dave Martin wrote: > >> 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 >> vari

Re: gcc: Thumb interworking and weakly linked functions

On 23/02/12 10:27, Aneesh V wrote: > Ok. Agree. I never used to use %function when I wrote assembly > functions earlier. I am sure a lot of code will break if this was > enforced. If you've not used %function on ARM, then your code is semantically broken even if it isn't syntactically broken. The

Re: Usefulness of GCC's 64bit __sync_* ops on ARM

On 08/07/11 17:04, Richard Henderson wrote: > On 07/08/2011 01:23 AM, Richard Earnshaw wrote: >> There is a slight performance hit to using a VDSO in that each entry >> will need to go through the PLT rather than jumping directly to the >> helper function in the kernel. &

Re: Usefulness of GCC's 64bit __sync_* ops on ARM

On 08/07/11 00:21, David Gilbert wrote: > On 5 July 2011 15:49, Dave Martin wrote: >> On Fri, Jul 1, 2011 at 6:10 PM, David Gilbert >> wrote: >>> Hi All, >>> I've just submitted the patches for the 64 bit atomic stuff to the >>> gcc-patches list. >>> Richard Henderson has raised the question of

Re: Usefulness of GCC's 64bit __sync_* ops on ARM

On Tue, 2011-05-31 at 16:03 +0100, David Gilbert wrote: > On 31 May 2011 15:35, Richard Earnshaw wrote: > > I think the difficulty here is that glibc expects either the compiler, > > or libgcc to provide the sync primitives; and while GCC can tie the > > inlined copy of th

Re: Usefulness of GCC's 64bit __sync_* ops on ARM

On Tue, 2011-05-31 at 13:17 +0100, Dave Martin wrote: > On Mon, May 30, 2011 at 09:38:25AM +0200, Ken Werner wrote: > > On 05/25/2011 03:17 PM, Dave Martin wrote: > > >On Wed, May 25, 2011 at 12:58:30PM +0100, David Gilbert wrote: > > >>On 25 May 2011 04:45, Nicolas Pitre wrote: > > >>>FWIW, here

Re: Usefulness of GCC's 64bit __sync_* ops on ARM

On Fri, 2011-05-06 at 17:06 +0200, Ken Werner wrote: > Hi, > > We've been thinking about adding support for the built-in functions for 64bit > atomic memory access and I'd like to know if this is of any interest. > Currently the main use of these functions seems to be to implement (SMP safe) >

Re: Capturing usage information

On Tue, 2010-08-10 at 10:26 +0100, Dave Martin wrote: > On Tue, Aug 10, 2010 at 10:16 AM, Loïc Minier wrote: > > On Mon, Aug 09, 2010, John Rigby wrote: > >> Does ltrace do what you want? > > > > This is what comes to my mind as well. > > > > There is a catch: I think eglibc (in fact almost all