[lttng-dev] Debian specific userspace RCU configure override

[Jon Bernard]

* Mathieu Desnoyers <mathieu.desnoyers at efficios.com> wrote:
> ----- Original Message -----
> > From: "Jon Bernard" <jbernard at debian.org>
> > To: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
> > Cc: "Ondřej Surý" <ondrej at sury.org>, "Michael Jeanson" <mjeanson at efficios.com>, "lttng-dev"
> > <lttng-dev at lists.lttng.org>
> > Sent: Tuesday, May 27, 2014 9:18:27 PM
> > Subject: Re: Debian specific userspace RCU configure override
> > 
> > * 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.
> 
> I'm afraid I don't understand what would need fixing in upstream urcu
> and lttng-tools. If two packages are built for different architectures
> (older ARM vs ARMv7+), I don't see how anyone would expect that both
> packages would be compatible.

As I currently understand, the debian build problem is that although the
package is compiled on armv7 hardware, it is expected to target armv4t.
And this is not correctly detected at configure-time.  The folks on
#debian-arm suggested that this could be solved in configure.ac.  I can
explicitly pass '--build <target>' to ./configure to get around this,
but arm users that build from source will need to remember this.

Also, this bug [1] was just filed which is related, I'm curious of your
thoughts on this.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749586

> > 
> >   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.
> 
> The issue here seems to be caused by the sparc build of urcu. Perhaps
> the override could be done only for sparc ? It is a bit special (see
> urcu README file for details).

Agreed, I'll revisit sparc and see where things stand after a consensus
is reached on the other topics.

Cheers,

-- 
Jon