[lttng-dev] Debian specific userspace RCU configure override

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Wed May 28 13:04:35 EDT 2014


----- 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.

> 
>   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).

Thoughts ?

Thanks,

Mathieu

> 
> Thoughts?
> 
> --
> Jon
> 

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



More information about the lttng-dev mailing list