I am using crosstool-ng to crosscompile for 68000 (version:crosstool-ng-1.24.0-rc2, host OS:Ubuntu 20.04)
My target is a 68000 (plain, not a 68020 or a cpu with floating point support).
I am compiling using a test program which multiplies two floats, using
-m68000 -mcpu=68000 -msoft-float -Wall -fno-builtin -O2
However, when I execute it, I get illegal instruction error
(notice, this happens only if I use floats)
Suspecting newlib is targeting 68020, I tried adding
CT_LIBC_NEWLIB_TARGET_CFLAGS="-m68000 -msoft-float"
but that made no difference.
What am I doing wrong? Do I need some code in the illegal instruction handler?
Related
I'm trying to cross-compile a file to flash into the Beaglebone Black.
All works fine, but if I try to enable the FPU with
#define set_en_bit_in_fpexc() do { \
int dummy; \
__asm__ __volatile__ ("fmrx %0,fpexc\n\t" \
"orr %0,%0,#0x40000000\n\t" \
"fmxr fpexc,%0" : "=r" (dummy) : :); \
} while (0)
I get the following error
Error: selected processor does not support `fmrx r3,fpexc' in ARM mode
Error: selected processor does not support `fmxr fpexc,r3' in ARM mode
I also tried with thumb mode, but I get the same errors.
Of course if I remove the part of the code that initialize the FPU it works fine.
Why I get those errors?
Makefile
[...]
CROSSPATH?=/usr/bin
CROSSPFX=$(CROSSPATH)/arm-none-eabi-
CC=$(CROSSPFX)gcc
AS=$(CROSSPFX)as
LD=$(CROSSPFX)ld
NM=$(CROSSPFX)nm
OBJCOPY=$(CROSSPFX)objcopy
OBJDUMP=$(CROSSPFX)objdump
CFLAGS=-Wall -Wextra -O2 -ffreestanding
ARCHFLAGS=-mcpu=cortex-a8 -march=armv7-a -mfpu=neon
CCARCHFLAGS=$(ARCHFLAGS) -marm
[...]
I'm on Arch, kernel 4.8.1
P.S. My professor uses the linaro cross-compiler and it works just fine
Most of the Linaro toolchains are configured for ARMv7 hard-float by default (certainly the Linux ones, I'm less sure about the bare-metal ones). Looking at the configuration of the arm-none-eabi toolchain as packaged by Arch, I surmise it's just using the GCC defaults for things like that, which implies something like ARMv4t, and crucially, soft-float ABI.
Whilst the -mfpu option controls code generation in terms of which floating-point instructions may be used, apparently it's the float ABI which controls whether it'll let you do things which really only make sense on a hardware FPU, rather than under floating-point emulation.
When it's not configured by default, you need to explicitly select a floating-point ABI implying an actual hardware FPU, i.e. -mfloat-abi=hard (or -mfloat-abi=softfp, but there's really no reason to use that unless you need to link against other soft-float code).
-mfpu=vfpv3-d16 -mfloat-abi=hard
Just to give a more direct solution, I had to add -mfpu=vfpv3-d16.
Test code a.S:
fmrx r2, fpscr
Working command:
sudo apt-get install binutils-arm-linux-gnueabihf
arm-linux-gnueabihf-as -mfpu=vfpv3-d16 -mfloat-abi=hard a.S
Note that -mfloat-abi=hard is enabled by default on this particular build of arm-linux-gnueabihf-as, and could be omitted.
The default value of float-abi likely depends on -msoft-float vs -mhard-float controlled at GCC build time with:
./configure --with-float=soft
as documented at: https://gcc.gnu.org/install/configure.html You can get the flags used for your toolchain build with gcc -v as mentioned at: What configure options were used when building gcc / libstdc++? I could not however easily determine its default value if not given.
You may also be interested in -mfloat-abi=softfp which can produce hard floats for the executable, but generate soft function calls: ARM compilation error, VFP registered used by executable, not object file
The possible values of -mfpu= can be found at: https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/ARM-Options.html#ARM-Options
Also note that FMRX is the pre-UAL syntax for VMRS which the newer recommended syntax, see also: Are ARM instructuons SWI and SVC exactly same thing?
Tested on Ubuntu 16.04, arm-linux-gnueabihf-as 2.26.1.
I am using g++ 4.8.4 on Linux 14.04 x64. I am compiling my project with -O3 and -flto flags both during compilation and linking i.e., both CFLAGS and LDFLAGS in my Makefile have these options.
I just discovered that the optimized binary behaves differently (i.e., wrongly) when it comes to computations involving float/double. Removing the -O3 from LDFLAGS alone seems to be solving the problem.
I remember reading somewhere that it is generally safe to specify the same set of optimization flags to both the compiler and the linker. Am I wrong in my understanding? Thanks in advance.
While using LTO, compiler during compilation step dumps intermediate code representation (a.k.a. GIMPLE) into special sections of the object files.
Actual compilation to machine codes and optimization happens during linking stage.
So yes, if your code is causing UB or just mis-optimized with -O3 option, it might behave differently (as expected) if you change it to -O0, -Og etc
So you have to find out whether it is your code misbehaving, or actual GCC LTO bug
when i am trying to compile the dhrystone benchmark in riscv-sodor for -march RV32I, an unrecognized opcode 'amoadd' error exits the compilation.
riscv-gcc -m32 -Wa,-march=RV32I -std=gnu99 -O2 -nostdlib -nostartfiles -DPREALLOCATE=1 -DHOST_DEBUG=0 \
-c -I../env -I./common -I./dhrystone ./dhrystone/dhrystone_main.c -o dhrystone_main.o
In file included from ./dhrystone/dhrystone_main.c:12:0:
./common/util.h:11:0: warning: "rdcycle" redefined [enabled by default]
./dhrystone/dhrystone.h:385:0: note: this is the location of the previous definition
/tmp/ccDLKK6P.s: Assembler messages:
/tmp/ccDLKK6P.s:16: Error: unrecognized opcode `amoadd'
make: *** [dhrystone_main.o] Error 1
Is there any way to compile the dhrystone for baremetal hardware of RV32I.
Remove the -Wa,-march=RV32I flag.
-Wa,-march=RV32I is telling the assembler to only accept valid RV32I instructions. It has found an amoadd instruction, so it properly errored out. The assembler is in no position to change out invalid instructions for valid instructions, that's the compiler's job.
Unfortunately, as of 2014 Dec, the riscv-toolchain's gcc port does not yet support -march=RV32I.
Instead, it is on the programmer to personally avoid writing code that will emit multiplies, AMOs, floating point, etc. In fact, the provided dhrystone code includes floating point instructions (I believe only in the initialization code) which would also cause -Wa,-march=RV32I to fail as well. In this situation, the programmer of dhrystone checks whether the processor supports floating point instructions and branches around them as required.
On a more academic note, I believe the amoadd is coming in from the common/util.h's "barrier" implementation. However, since dhrystone does not call barrier, I'm unsure why the assembler is being passed an amoadd instruction. I certainly don't see it in my own disassemblies of dhrystone. I also was unable to reproduce your error on my own RISCV compilers. I am using a riscv-gcc from early August 2014 (https://github.com/ucb-bar/riscv-tools) and a newer gcc4.9 found at (https://github.com/ucb-bar/riscv-tools/tree/new-abi), which is in testing, but will soon be moved to master (~Jan 2015).
I am compiling a C file using the gcc flag -ffunction-sections, to move every function into it's own section. The assembler is throwing the error:
job_queue.s:2395: Error: operation combines symbols in different segments
The compiler's assembly output at line 2395 is given here:
.section .debug_ranges,info
.Ldebug_ranges0:
.4byte .LBB7-.Ltext0
The symbol LBB7 is in the function (and thus the section) named ".text.add_event_handler"
The symbol Ltext0 is in the (otherwise empty) section named: ".text"
GCC --version gives:
pic30-elf-gcc.exe (GCC) 4.0.3 (dsPIC30, Microchip v3_30) (B) Build date: Jun 29 2011
If I use the compiler flag -g0 (to turn off debug info) everything compiles and runs perfectly.
My question:
Is this GCC output clearly wrong? It seems to me that GCC should have calculated the symbol LBB7's offset from the beginning of the .add_even_handler section instead of the .text section.
I suspect I am misunderstanding something because I cannot find anyone having the same difficulty on the Google.
The GCC output is definitely wrong. Perhaps it's fixed in newer GCC versions. If you can't upgrade you compiler, try compiling with -gdwarf-2 or, failing that, with -gdwarf-2 -gstrict-dwarf (for -gstrict-dwarf you'll have to upgrade the compiler too).
What this option does is to instruct GCC to generate (strict) DWARF2, which does not include non-contiguous address ranges support, introduced in DWARF3.
Of course, this may degrade the debugging information quality somewhat, YMMV.
Is it (easily) possible to use software floating point on i386 linux without incurring the expense of trapping into the kernel on each call? I've tried -msoft-float, but it seems the normal (ubuntu) C libraries don't have a FP library included:
$ gcc -m32 -msoft-float -lm -o test test.c
/tmp/cc8RXn8F.o: In function `main':
test.c:(.text+0x39): undefined reference to `__muldf3'
collect2: ld returned 1 exit status
It is surprising that gcc doesn't support this natively as the code is clearly available in the source within a directory called soft-fp. It's possible to compile that library manually:
$ svn co svn://gcc.gnu.org/svn/gcc/trunk/libgcc/ libgcc
$ cd libgcc/soft-fp/
$ gcc -c -O2 -msoft-float -m32 -I../config/arm/ -I.. *.c
$ ar -crv libsoft-fp.a *.o
There are a few c files which don't compile due to errors but the majority does compile. After copying libsoft-fp.a into the directory with our source files they now compile fine with -msoft-float:
$ gcc -g -m32 -msoft-float test.c -lsoft-fp -L.
A quick inspection using
$ objdump -D --disassembler-options=intel a.out | less
shows that as expected no x87 floating point instructions are called and the code runs considerably slower as well, by a factor of 8 in my example which uses lots of division.
Note: I would've preferred to compile the soft-float library with
$ gcc -c -O2 -msoft-float -m32 -I../config/i386/ -I.. *.c
but that results in loads of error messages like
adddf3.c: In function '__adddf3':
adddf3.c:46: error: unknown register name 'st(1)' in 'asm'
Seems like the i386 version is not well maintained as st(1) points to one of the x87 registers which are obviously not available when using -msoft-float.
Strangely or luckily the arm version compiles fine on an i386 and seems to work just fine.
Unless you want to bootstrap your entire toolchain by hand, you could start with uclibc toolchain (the i386 version, I imagine) -- soft float is (AFAIK) not directly supported for "native" compilation on debian and derivatives, but it can be used via the "embedded" approach of the uclibc toolchain.
GCC does not support this without some extra libraries. From the 386 documentation:
-msoft-float Generate output containing library calls for floating
point. Warning: the requisite
libraries are not part of GCC.
Normally the facilities of the
machine's usual C compiler are used,
but this can't be done directly in
cross-compilation. You must make your
own arrangements to provide suitable
library functions for
cross-compilation.
On machines where a function returns
floating point results in the 80387
register stack, some floating point
opcodes may be emitted even if
-msoft-float is used
Also, you cannot set -mfpmath=unit to "none", it has to be sse, 387 or both.
However, according to this gnu wiki page, there is fp-soft and ieee. There is also SoftFloat.
(For ARM there is -mfloat-abi=softfp, but it does not seem like something similar is available for 386 SX).
It does not seem like tcc supports software floating point numbers either.
Good luck finding a library that works for you.
G'day,
Unless you're targetting a platform that doesn't have inbuilt FP support, I can't think of a reason why you'd want to emulate FP support.
Doesn't your x386 platform have external FPU support? Pity it's not a x486 with the FPU built in!
In my experience, any soft emulation is bound to be much slower than its hardware equivalent.
That's why I finished up writing a package in Ada to taget the onboard 68k FPU instead of using the soft emulation provided by the compiler manufacturer at the time. They finished up bundling it in their compiler as a matter of fact.
Edit: Just seen your comment below. Hmmm, if you don't need a full suite of FP support is it possible to roll your own for the few math functions you do need? That how the Ada package I mentioned got started.
HTH
cheers,