Re: [PATCH] xen/x86: don't use '.ifnes' in bug frame construction.

[Tim Deegan <tim@xen.org>]

At 09:29 +0100 on 30 Aug (1377854957), Jan Beulich wrote:
> >>> On 29.08.13 at 17:55, Tim Deegan <tim@xen.org> wrote:
> > Spotted because it breaks the clang build for LLVM <3.2.  .ifnes is
> > not right here as it will choke on a string with embedded quotes.
> > 
> > .ifnb would be better except that LLVM <3.2 doesn't support that either.
> > It should be possible to use something like !!msg or !!msg[0] instead
> > of a separate flag, but I gave up trying to find something that would
> > make it through CPP, asm() and gas as a usable constant. :|
> 
> I'm not really opposed to this (albeit I dislike redundancy like this),
> but I'd really like to understand (also for the sake of my own
> education, including to avoid introducing similar breakage in the
> future) where the problem was, and how gcc+gas manage to
> accept what you appear to have found broken in general (i.e. not
> just for clang as I understand it).

The clang failure is just that the fancier .if operations are not
supported until LLVM 3.2 (and Xen builds file with 3.0 otherwise).

The problem with [.ifnes \"" msg "\" \"\"] is that .ifeqs and .ifnes
expect "-delimited strings and (at least in my testing yesterday) will
fail when msg has a quote in it.  That doesn't happen in the current
Xen tree but something like ASSERT(strlen("boo") == 3) or the
ASSERT(predicate() && "explanatory message") idiom would fail.

> And yes, I would have preferred (and used) .ifnb if I hadn't recalled
> it having been me adding the support for it for binutils 2.17, while at
> least one of the so far lowest common denominator distros (SLE10)
> is only at 2.16.<something> (which appears to have the needed
> support, but it would seem wrong to draw the line at some
> intermediary release); not sure what binutils version RHEL5 uses.

Righto.  Can I have an Ack/Nack please, since Keir defers to you and
I've run out of x86 maintainers? :)

Tim.