[lttng-dev] Multiple local register variables w/ same register

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Tue Nov 19 17:34:57 EST 2013


----- Original Message -----
> From: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
> To: "Richard Henderson" <rth at twiddle.net>
> Cc: "Jakub Jelinek" <jakub at redhat.com>, gcc at gcc.gnu.org, "Peter Zijlstra" <peterz at infradead.org>, "Catalin Marinas"
> <Catalin.Marinas at arm.com>, "Nathan Lynch" <Nathan_Lynch at mentor.com>, linux-kernel at vger.kernel.org, "Will Deacon"
> <will.deacon at arm.com>, lttng-dev at lists.lttng.org, "Andrew Morton" <akpm at linux-foundation.org>, "Paul E. McKenney"
> <paulmck at linux.vnet.ibm.com>, "Linus Torvalds" <torvalds at linux-foundation.org>
> Sent: Tuesday, November 19, 2013 5:25:18 PM
> Subject: Re: [lttng-dev] Multiple local register variables w/ same register
> 
> ----- Original Message -----
> > From: "Richard Henderson" <rth at twiddle.net>
> > To: "Peter Zijlstra" <peterz at infradead.org>, "Mathieu Desnoyers"
> > <mathieu.desnoyers at efficios.com>
> > Cc: "Will Deacon" <will.deacon at arm.com>, linux-kernel at vger.kernel.org,
> > "Catalin Marinas" <Catalin.Marinas at arm.com>,
> > lttng-dev at lists.lttng.org, "Nathan Lynch" <Nathan_Lynch at mentor.com>, "Paul
> > E. McKenney"
> > <paulmck at linux.vnet.ibm.com>, "Linus Torvalds"
> > <torvalds at linux-foundation.org>, "Andrew Morton"
> > <akpm at linux-foundation.org>, "Jakub Jelinek" <jakub at redhat.com>,
> > gcc at gcc.gnu.org
> > Sent: Tuesday, November 19, 2013 4:56:57 PM
> > Subject: Multiple local register variables w/ same register
> > 
> > On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
> > > On Tue, Nov 19, 2013 at 05:02:20PM +0000, Mathieu Desnoyers wrote:
> > >> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan
> > >> could
> > >> test
> > >> it for us though.
> > >>
> > >> It might shuffle things around enough to work around the issue, but with
> > >> the
> > >> approach you propose, I would be concerned about the compiler being
> > >> within
> > >> its rights to reorder the code into the following sequence:
> > >>
> > >> struct thread_info *ptra, *ptrb;
> > >>
> > >> ptra = current_thread_info();
> > >> /*
> > >>  * each current_thread_info() would have a clobber on *sp, which orders
> > >>  * those two wrt each other.
> > >>   */
> > >> ptrb = current_thread_info();
> > >>
> > >> load from ptra->preempt_count;
> > >> /*
> > >>  * however, the following accesses that depend on ptra and ptrb could be
> > >>  * reordered if the compiler has no way to know that ptra and ptrb are
> > >>  * aliased.
> > >>  */
> > >> store to ptrb->preempt_count;
> > >>
> > >> One question that might be worth asking: with the local register
> > >> variable
> > >> extension
> > >> (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
> > >> (thanks to Jakub for the pointer), should the compiler consider two
> > >> variables
> > >> bound to the same register as being aliased or not ? AFAIU, local reg
> > >> vars
> > >> appear
> > >> to be architecture-specific, so maybe there is something fishy on ARM ?
> > 
> > It appears not:
> > 
> > int __attribute__((noinline)) f(void)
> > {
> >   {
> >     register int x __asm__("eax");
> >     x = 1;
> >   }
> >   {
> >     register int y __asm__("eax");
> >     return ++y;
> >   }
> > }
> > 
> > extern void abort(void);
> > 
> > int main(void)
> > {
> >   if (f() != 2)
> >     abort();
> >   return 0;
> > }
> > 
> > Anyone see anything wrong with the testcase?
> 
> This testcase is targeting a general purpose register, whereas the issue I'm
> presenting gets the stack pointer as base address for many memory operations
> targeting the same offset from this base address. So strictly speaking, I
> think the two cases are slightly different.

By the way, I just had more info from Nathan, where a splat clearly shows a scheduling while atomic, which points rather to an unbalanced preempt enable/disable within LTTng. It's weird though, because so far it only triggers on ARM, and only with gcc 4.8.x. Don't waste your time on this one until we can figure out if the issue is within LTTng.

Thanks,

Mathieu

> 
> Thanks,
> 
> Mathieu
> 
> 
> > Do we thing this sort of thing
> > ought to work, perhaps with scopes lengthened?
> > 
> > 
> > r~
> > 
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com



More information about the lttng-dev mailing list