Hi,
Trying to compile libcxxabi on ARM/Linux with clang ToT, I get:
cd /home/ismail/libcxxabi/build/src/Unwind && /havana/dist/llvm/bin/clang -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -Werror=date-time -ffunction-sections -fdata-sections -I/home/ismail/libcxxabi/include -I/home/ismail/libcxx/include -UNDEBUG -fPIC -o CMakeFiles/unwind.dir/UnwindRegistersRestore.S.o -c /home/ismail/libcxxabi/src/Unwind/UnwindRegistersRestore.S
/home/ismail/libcxxabi/src/Unwind/UnwindRegistersRestore.S:350:24: error: unknown token in expression
ldc p11, cr0, [r0], {#0x20} @ fldmiad r0, {d0-d15}
^
/home/ismail/libcxxabi/src/Unwind/UnwindRegistersRestore.S:350:24: error: illegal expression
ldc p11, cr0, [r0], {#0x20} @ fldmiad r0, {d0-d15}
^
/home/ismail/libcxxabi/src/Unwind/UnwindRegistersRestore.S:361:24: error: unknown token in expression
ldc p11, cr0, [r0], {#0x21} @ fldmiax r0, {d0-d15}
^
/home/ismail/libcxxabi/src/Unwind/UnwindRegistersRestore.S:361:24: error: illegal expression
ldc p11, cr0, [r0], {#0x21} @ fldmiax r0, {d0-d15}
^
/home/ismail/libcxxabi/src/Unwind/UnwindRegistersRestore.S:372:25: error: unknown token in expression
ldcl p11, cr0, [r0], {#0x20} @ vldm r0, {d16-d31}
^
/home/ismail/libcxxabi/src/Unwind/UnwindRegistersRestore.S:372:25: error: illegal expression
ldcl p11, cr0, [r0], {#0x20} @ vldm r0, {d16-d31}
^
This works with the gnu as (tested using -no-integrated-as). Is this a known problem?
Thanks!
Hi Ismail,
Don't remember to have seen this one before. Please fill a bug with
this, make it a dependency for 18926 and assign to me, I'll have a
look.
cheers,
--renato
That's what I get for not having a buildbot on it... 
I used to build libc++/abi weekly but things went haywire for the last
two months and I stopped any background tasks. This was introduced in
libc++abi by the end of June, I believe, after I stopped testing.
It looks like we understand the curly-integer as the co-processor
option, but there must be something wrong with the parser before that
that screws up things as it gets to it. I'm having a look right now.
cheers,
--renato
PS: the buildbot is on my long list of "never done but should have"
things... sigh...
Renato,
I have a Linux buildbot configuration for libc++ and libc++abi in the works. Hopefully can get that checked in later today…
Oh, shiny! 
I'll be glad to test it on ARM bots.
cheers,
--renato
Could
[unwinder] Tell the assembler that functions are functions so that th… · llvm-mirror/libcxxabi@a09f807 · GitHub
be related?
Nope. These probably creeped in because the NDK folks are building with gcc, and I'm using -fno-integrated-as. I would be a happy camper if both -fintegrated-as and -fno-integrated-as both worked though...
If I remember correctly, these coprocessor synonyms were put in so that we could assemble these instructons even for chips that don't support them, making the multilib more universal. What would it take to get IAS to understand this syntax?
Cheers,
Jon
Try the attached patch, please.
Joerg
UnwindRegistersRestore.S.diff (6.42 KB)
One step is to change libc++abi to not use immediate syntax on
numbers, another is probably a bug in the MC emitter.
http://llvm.org/bugs/show_bug.cgi?id=20529
cheers,
--renato
Hi Joerg,
The IMM doesn't make much sense. Simply removing the hash fixes it,
and it also works on GAS, so win win.
I have a fix for the other part, too.
cheers,
--renato
Hi Joerg,
Reading it back again, it sounded a bit harsh from my part, I didn't
mean it, sorry.
What I meant is that the immediate syntax doesn't apply to that
argument, but still applies to other immediates. At least, that's what
I read from the ARM ARM, which only states that the value is encoded
in the immediate field, not that it has immediate syntax, and even
making it a separate syntax from the other immediate lines, rather
than an addressing mode, which would then imply similar syntax.
I'd be curious of how other people did it in the past and if the
default usage is with the hash, we may be forced to implement it that
way. GAS accepts both.
On the other hand, for ARMv5/6, you can already use cp10/cp11 in
coprocessor instructions, but not on v7/v8 and that's (now)
intentional. Access to those registers have been disabled in those
architectures in preference for direct vector instructions, and we'll
*have* to do it at least for AArch64, why not for v7 too?
I may be wrong, but I think it's a sane restriction. I'm CC'ing
Richard just in case he has more to say, or a better argument against
v7/v8 cp10/11 access and on the immediate syntax issue.
cheers,
--renato