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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.08.13 at 11:43, Tim Deegan <tim@xxxxxxx> wrote:
> At 09:29 +0100 on 30 Aug (1377854957), Jan Beulich wrote:
>> >>> On 29.08.13 at 17:55, Tim Deegan <tim@xxxxxxx> 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? :)

Sure:
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

As said, before acking I merely wanted to understand why I
didn't see any issue, and what to avoid in the future.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel