Date:	Tue, 19 Nov 2013 22:34:57 +0000 (UTC)
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	Richard Henderson <rth@...ddle.net>
Cc:	Jakub Jelinek <jakub@...hat.com>, gcc@....gnu.org,
	Peter Zijlstra <peterz@...radead.org>,
	Catalin Marinas <Catalin.Marinas@....com>,
	Nathan Lynch <Nathan_Lynch@...tor.com>,
	linux-kernel@...r.kernel.org, Will Deacon <will.deacon@....com>,
	lttng-dev@...ts.lttng.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [lttng-dev] Multiple local register variables w/ same register

----- Original Message -----
> From: "Mathieu Desnoyers" <mathieu.desnoyers@...icios.com>
> To: "Richard Henderson" <rth@...ddle.net>
> Cc: "Jakub Jelinek" <jakub@...hat.com>, gcc@....gnu.org, "Peter Zijlstra" <peterz@...radead.org>, "Catalin Marinas"
> <Catalin.Marinas@....com>, "Nathan Lynch" <Nathan_Lynch@...tor.com>, linux-kernel@...r.kernel.org, "Will Deacon"
> <will.deacon@....com>, lttng-dev@...ts.lttng.org, "Andrew Morton" <akpm@...ux-foundation.org>, "Paul E. McKenney"
> <paulmck@...ux.vnet.ibm.com>, "Linus Torvalds" <torvalds@...ux-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@...ddle.net>
> > To: "Peter Zijlstra" <peterz@...radead.org>, "Mathieu Desnoyers"
> > <mathieu.desnoyers@...icios.com>
> > Cc: "Will Deacon" <will.deacon@....com>, linux-kernel@...r.kernel.org,
> > "Catalin Marinas" <Catalin.Marinas@....com>,
> > lttng-dev@...ts.lttng.org, "Nathan Lynch" <Nathan_Lynch@...tor.com>, "Paul
> > E. McKenney"
> > <paulmck@...ux.vnet.ibm.com>, "Linus Torvalds"
> > <torvalds@...ux-foundation.org>, "Andrew Morton"
> > <akpm@...ux-foundation.org>, "Jakub Jelinek" <jakub@...hat.com>,
> > 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@...ts.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists