Trying to use the UB sanitizer for AVR target gives:
avr-gcc -Wall -mmcu=attiny1614 -fsanitize=undefined bm02.c
/usr/local/lib/gcc/avr/10.0.0/../../../../avr/bin/ld: cannot find
-lubsan collect2: error: ld returned 1 exit status
Can one build the avr-gcc with UBsan support?
No.
Currently, avr-g++ has no full C++ support, and for such targets, the toplevel configure.ac switches off libsanitizer. This is because libsanitizer is written in C++, cf. ubsan sources.
Related
I have these flags in my Makefile and it works:
gcc -mtune=i386 -m32
ld -m elf_i386
What is the difference between those and cross compiler i386-elf-gcc?
core of stm32f10x should be cortex-m3,with the flag"-mcpu=cortex-m3" ↓(this is section of makefile ):
CFLAGS += -T$(STD_PERIPH_LIBS)/Project/STM32F10x_StdPeriph_Template/TrueSTUDIO/STM3210B-EVAL/stm32_flash.ld
CFLAGS += -mlittle-endian -mthumb -mcpu=cortex-m3 -mthumb-interwork
CFLAGS += -mfloat-abi=hard -mfpu=fpv4-sp-d16
the error :
/root/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: error: /tmp/ccwnNCUm.o uses VFP register arguments, t1.elf does not
/root/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /tmp/ccwnNCUm.o
/root/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: error: /tmp/ccaQhPT1.o uses VFP register arguments, t1.elf does not
/root/gcc-arm-none-eabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /tmp/ccaQhPT1.o
collect2: error: ld returned 1 exit status
Makefile:39: recipe for target 't1.elf' failed
make: *** [t1.elf] Error 1
but after replacing "-mcpu=cortex-m3" with "-mcpu=cortex-m4",the error disappears and the program runs normally.
this introduction of "st.com"
STM32F103 devices use the Cortex-M3 core, with a maximum CPU speed of
72 MHz.
so why is it "-mcpu=cortex-m4" instead of "-mcpu=cortex-m3"?
my arm-none-eabi-gcc:
gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision
277599] (GNU Tools for Arm Embedded Processors 9-2019-q4-major)
Cortex-m3 doesn't have FPU option
When I try to compile a trivial example test.c
int main () {
return 0;
}
for a cortex m7 target with hard float ABI by using the following invocation
arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nosys.specs test.c
I get this error:
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o: Conflicting CPU architectures 13/1
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: a.out uses VFP register arguments, /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libc.a(lib_a-atexit.o) does not
[snip]
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libnosys.a(_exit.o)
collect2: error: ld returned 1 exit status
So the issue is that gcc is linking to the wrong libc.a. If I use the argument print-multi-directory, it would appear that my version of arm-none-eabi-gcc should support this architecture:
$ arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nosys.specs --print-multi-directory
thumb/v7e-m/fpv5/hard
And I can list the different versions of libc.a that are provided by arm-none-eabi-gcc:
$ find /usr/lib/arm-none-eabi/ -name libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-sp-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-sp-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-d16/libc.a
/usr/lib/arm-none-eabi/newlib/libc.a
/usr/lib/arm-none-eabi/newlib/armv6-m/libc.a
/usr/lib/arm-none-eabi/newlib/fpu/libc.a
/usr/lib/arm-none-eabi/newlib/thumb/libc.a
/usr/lib/arm-none-eabi/newlib/armv7-m/libc.a
So it looks like there is a version of libc.a compiled for my desired architecture, but gcc isn't linking against it. How can I get gcc to link against the correct version of libc.a?
I'm using arm-none-eabi-gcc version 6.3.1 provided by the gcc-arm-none-eabi package for Ubuntu 18.04.
I'd like to know if I can use different compilers for compile and link.
For example ,I have two files ,a.c and b.c,
I use clang to compile a.c and b.c:
clang -c a.c -o a.o
clang -c b.c -o b.o
and then use gcc to link the two .o file as a so library:
gcc -lm -lz -shared a.o b.o -o libad.so
I generate the so file successfully,but the app will crash when using this library.
Update:
More detailed information: What I have done is cross-compile , and target platform is armv7a.I use android-NDK and compile the codes on MAC.So the gcc is arm-linux-androideabi-gcc and clang is arm-linux-androideabi-clang.
Unless special flags are specified at link time (-fuse-ld=xxx[1][2]), both clang and gcc call the default system linker (which on macOS is lld and will probably be gold on linux). So running the second statement with either gcc or clang will produce the same linked binary.
[1] https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
[2] http://clang-developers.42468.n3.nabble.com/LLD-to-be-the-default-linker-in-Clang-td4053949.html
I'm using GCC 4.7.2 and LD 2.23 but when I add -flto to my compile options my compile time increases by over 20%! The manual seems to indicate that -fuse-linker-plugin is needed for the optimization to work. It also says that it's enabled by default with -flto but when I add it explicitly I see the following error in the link command:
g++: error: -fuse-linker-plugin is not supported in this configuration
According to manual, it should be supported by LD 2.21 or greater. Any idea why I'm getting this error? For reference here are examples of my full compile commands:
g++ -Wall -pipe -O3 -flto -fno-strict-aliasing -mtune=generic --no-exceptions -fPIC -c some.cc
g++ -o exec -Xlinker some1.o some2.o -static some1.a some2.a -Wl,--wrap,open -flto -fuse-linker-plugin
Running 'ld --help | grep plugin' shows "-plugin" option so I don't understand why GCC is complaining:
-plugin PLUGIN Load named plugin
-plugin-opt ARG Send arg to last-loaded plugin
Link time optimizations aren't supposed to reduce compilation time, but optimize runtime of your program.
#options, just add "-flto -fuse-linker-plugin" to your CFLAGS(or CXXFLAGS for c++) and LDFLAGS and it should work just fine.
#gold: ld --version is probably gonna return gnu LD, to switch to gold, make ld symlink which ld point to which ld.gold
e.g. ln -s /usr/bin/ld.gold /usr/bin/ld