Hi,
I have submitted a bug some time ago to LLVM bugtracker:
http://llvm.org/bugs/show_bug.cgi?id=8931
The problem is that I'm trying to use clang in linux system, running
on ARM hardware. And this bug, as trivial as it is, seems to be a major
showstopper.
I wonder if I'm the only one trying to use LLVM/clang in this configuration
or doing something in an unusual way? Anyway, the LLVM sources contain a
comment "// FIXME: Emit FPU type", implying that emitting FPU type was
actually planned.
Would it be possible to fix this problem somehow? Being able to use clang
in linux on ARM systems may provide additional testing coverage, so should
be beneficial for LLVM project in the long run.
Thanks.
Hi Siarhei,
This is a really silly bug with a simple fix.
We have a similar patch here locally, but as this is part of another
set of patches we were waiting for it to stabilise. There are some
other build attributes that need to be set when you're using NEON or
VFP, but I'll try to get them working without any other modification
as a clean cut patch.
I'll round it up and submit the patch. Thanks for reminding about it.
cheers,
--renato
OK, thanks. It's good to know that somebody is working on this.
LLVM/clang is making a really good progress with the regards to ARM support
and I'm looking forward to the next release. Other than this minor issue,
clang 2.8 already looks quite good and can be used to successfully compile
some real programs on ARM (and do this correctly enough to pass regression
tests).
Hi Renato,
I noticed that support for some elf eabi attributes has been added to LLVM and
it is a good progress. But still this is insufficient.
Now with the schedule for 2.9 available, would it be possible to resolve this
missing ".fpu" directive issue for 2.9 release in order to have clang working
on ARM linux systems out of the box without patching?
Thanks.
> I have submitted a bug some time ago to LLVM bugtracker:
> http://llvm.org/bugs/show_bug.cgi?id=8931
Hi Siarhei,
This is a really silly bug with a simple fix.
We have a similar patch here locally, but as this is part of another
set of patches we were waiting for it to stabilise. There are some
other build attributes that need to be set when you're using NEON or
VFP, but I'll try to get them working without any other modification
as a clean cut patch.
I'll round it up and submit the patch. Thanks for reminding about it.
Hi Renato,
I noticed that support for some elf eabi attributes has been added to LLVM and
it is a good progress. But still this is insufficient.
Now with the schedule for 2.9 available, would it be possible to resolve this
missing ".fpu" directive issue for 2.9 release in order to have clang working
on ARM linux systems out of the box without patching?
Hi Siarhei,
if you can get us the sequence of attributes you want emitted for each fpu type,
and what you expect to see on the .o side, it should be very possible
to get that squared away for the release.
-jason
The elf attributes and cpu/fpu type directives are a bit different things. The
former are the extra information in .o files to be used by static or dynamic
linker. The latter are the directives to assembler, and if you don't specify
the right cpu/fpu type, the assembly code is rejected by gnu assembler and
no .o file is generated at all. Currently LLVM emits ".cpu" directive, but
totally forgets about ".fpu", and this causes problems.
My proposed patch is available in LLVM bug 8931, and I'm also pasting it here
for more convenience:
Index: lib/Target/ARM/ARMAsmPrinter.cpp
Hi Siarhei,
I've got the patch in my hands, sorry for the delay.
It takes into account the MC emitting the .fpu when in ASM mode and
the build attributes in both ASM and ELF mode.
Jason, that's the patch I was talking about today. It's non-invasive
and I'll send it no later than Monday, so should be in for the 2.9
release.
cheers,
--renato
Wonderful! Looking forward to seeing it!
-jason