[lttng-dev] Debian specific userspace RCU configure override

Jon Bernard jbernard at debian.org
Tue May 27 21:18:27 EDT 2014

* Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote:
> ----- Original Message -----
> > From: "Jon Bernard" <jbernard at debian.org>
> > To: "Ondřej Surý" <ondrej at sury.org>
> > Cc: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>, "Michael Jeanson" <mjeanson at efficios.com>, "lttng-dev"
> > <lttng-dev at lists.lttng.org>
> > Sent: Tuesday, May 27, 2014 4:18:48 PM
> > Subject: Re: Debian specific userspace RCU configure override
> > 
> > * Ondřej Surý <ondrej at sury.org> wrote:
> > > On Sun, May 25, 2014, at 2:59, Mathieu Desnoyers wrote:
> > > > Why are each package compiled against completely different targets ?
> > > 
> > > urcu invokes ./configure manually while ltt-control uses
> > > dh_auto_configure wrapper and that makes the difference
> > 
> > This is correct.  When I first saw the difference, I assumed they would
> > both invoke configure in a way that wouldn't effect the target.  But now
> > I remember having a similar problem on sparc (which is why urcu includes
> > this override) where the target discovery was not correct.
> > 
> > It looks to me like a bug related to debhelper (which provides
> > dh_auto_configure).  For now, I think this override applied to
> > lttng-tools will correctly fix the build without disabling dmb.  I will
> > let the existing transition into testing complete and then submit new
> > packages.
> The big question here: is it OK to generate "dmb" instruction ? If the
> intent of this architecture support is to cover earlier-than-armv7 ARM
> processors, then "dmb" should not be explicitly generated, and therefore
> URCU configuration would need fixing. If the intent of this Debian arch
> is to cover only ARMv7 and better, then it's lttng-tools that needs
> fixing.

So my assumption was wrong, debian armel targets armv4t (armhf targets
v7).  The build machines happen to be running a v7 kernel, but the build
must honor the target which is 'arm-unknown-linux-gnueabi' in this case
(implying no dmb instructions).

So, lttng-tools (which uses the dh wrapper) is correctly detecting the
build target.  This is because it's calling autoreconf and passing
additional '--build' and '--host' parameters to ./configure.  If
I change liburcu to use this wrapper by removing the explicit configure
override, it too detects the correct build target and disables dmb
instructions as it should.

So two things come to mind:

  1.  Technically, upstream doesn't need to do anything for this change
      to correctly resolve the existing issues in Debian.  But it does
      mean that non-debian arm builds may discover an incorrect build
      target and produce incompatible object code if the user doesn't
      regenerate the build system files and call configure in a similar
      way.  Personally, I would like to see this fixed for everyone, so
      a fix to both urcu and lttng-tools configure scripts seems
      appropriate.  I'm more than happy to test any patches on the
      resources to which I have access.

  2.  Using the dh wrapper is considered best-practice, so liburcu
      should be conforming to this.  I need to re-test the change on
      sparc and make sure I'm not in a world of hurt.



More information about the lttng-dev mailing list