Why GCC can't pass options to `gas` assembler with `-Wa,-adhln=a.lst`? - gcc

When I want to generate the list file of a.c with the name a.lst, I execute the command:
gcc -v -S -Wa,-adhln=a.lst a.c
and some of the output is as following:
gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2)
COLLECT_GCC_OPTIONS='-v' '-S' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/5/cc1 -quiet -v -imultiarch x86_64-linux-gnu a.c -quiet -dumpbase a.c -mtune=generic -march=x86-64 -auxbase a -version -o a.s -fstack-protector-strong -Wformat -Wformat-security
So, according to the output, I can't find the options of assembler -adhln=a.lst is being passed, and there is no a.lst file generated. My gcc version is gcc (Ubuntu 5.3.1-14ubuntu2) 5.3.1 20160413, as version is GNU assembler (GNU Binutils for Ubuntu) 2.26. What's wrong with me?

The -Wa option passes flags to the assembler.
Your command uses -S which means "do not run the assembler".

Related

The clang equivalent for the gcc -O

How to do in clang the gcc -O optimizing option equivalent?
gcc -O3 -o tes tes.cpp
on clang ...?
You do exactly the same.
clang -O3 -o tes tes.cpp

Cross compiling with arm-linux-gnueabihf

I am quite new to cross compiling. After downloading the arm-linux-gnueabihf tool from arm. I tried to use the binary called arm-linux-gnueabihf-g++ and arm-linux-gnueabihf-gcc to compile my code. My command looks something like:
~/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -Isrc -I/usr/include -std=c++11 -Wall -Wno-unknown-pragmas -O0 -g3 -D__DEBUG_BUILD__ -DDEVELOPMENT -MMD -c -o "Debug/src/BatteryStatus.o" "src/BatteryStatus.cpp"
I immediately run into this issue:
~/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/arm-linux-gnueabihf/libc/usr/include/stdlib.h:133:35: error: missing binary operator before token "("
#if __HAVE_FLOAT16 && __GLIBC_USE (IEC_60559_TYPES_EXT)
It's weird that the issue happens in the tool chain, I would expect some incompatibilities in the libraries I am using. The environment entails CentOS 7.2, c++ 11 and I am compiling for an ARM 32-bit target on a x86_64 host machine. Building a simple hello world program went fine, it compiled and ran successfully on the target machine.
You are pointing to your native header files directory, /usr/include, in your build command. This is very likely the cause of your problem. Try this command instead:
~/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -Isrc -std=c++11 -Wall -Wno-unknown-pragmas -O0 -g3 -D__DEBUG_BUILD__ -DDEVELOPMENT -MMD -c -o "Debug/src/BatteryStatus.o" "src/BatteryStatus.cpp
The default directories used by the toolchain can be displayed using:
echo | /opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc -v -x c -E -
Using built-in specs.
COLLECT_GCC=/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc
Target: arm-linux-gnueabihf
Configured with: /tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/src/gcc/configure --target=arm-linux-gnueabihf --prefix= --with-sysroot=/arm-linux-gnueabihf/libc --with-build-sysroot=/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/build-arm-linux-gnueabihf/install//arm-linux-gnueabihf/libc --with-bugurl=https://bugs.linaro.org/ --enable-gnu-indirect-function --enable-shared --disable-libssp --disable-libmudflap --enable-checking=release --enable-languages=c,c++,fortran --with-gmp=/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/build-arm-linux-gnueabihf/host-tools --with-mpfr=/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/build-arm-linux-gnueabihf/host-tools --with-mpc=/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/build-arm-linux-gnueabihf/host-tools --with-isl=/tmp/dgboter/bbs/rhev-vm8--rhe6x86_64/buildbot/rhe6x86_64--arm-linux-gnueabihf/build/build-arm-linux-gnueabihf/host-tools --with-arch=armv7-a --with-fpu=neon --with-float=hard --with-arch=armv7-a --with-pkgversion='GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)'
Thread model: posix
gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))
COLLECT_GCC_OPTIONS='-v' '-E' '-mfloat-abi=hard' '-mfpu=neon' '-mtls-dialect=gnu' '-marm' '-march=armv7-a+simd'
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/8.3.0/cc1 -E -quiet -v -iprefix /opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/ -isysroot /opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc - -mfloat-abi=hard -mfpu=neon -mtls-dialect=gnu -marm -march=armv7-a+simd
ignoring duplicate directory "/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/../../lib/gcc/arm-linux-gnueabihf/8.3.0/include"
ignoring nonexistent directory "/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/usr/local/include"
ignoring duplicate directory "/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/../../lib/gcc/arm-linux-gnueabihf/8.3.0/include-fixed"
ignoring duplicate directory "/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/../../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/include
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/include-fixed
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/include
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/usr/include
End of search list.
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/arm-linux-gnueabihf/libc/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "<stdin>"
COMPILER_PATH=/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../libexec/gcc/arm-linux-gnueabihf/8.3.0/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../libexec/gcc/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/bin/
LIBRARY_PATH=/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/lib/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/lib/:/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-E' '-mfloat-abi=hard' '-mfpu=neon' '-mtls-dialect=gnu' '-marm' '-march=armv7-a+simd'
That is, on my system, the correct, default directories for the header files would be:
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/include
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/include-fixed
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/include
/opt/arm/gcc-arm-8.3-2019.03-x86_64-arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/usr/include
and not /usr/include.

How to convert assembly code to executable in LLVM

I have converted c program into assembly code using following commands in LLVM :
clang -emit-llvm matrix.c -c -o matrix.bc
llc -march=alpha matrix.bc -o matrix.s
Now how to convert matrix.s assembly file into executable file of alpha.
How to do that?
clang can also be used
clang matrix.s -L [additional library locations] -mllvm -Wall -g -L. -Wl,-pie -I. -I[additional include locations] -o [executable output]
Adjust the flags as your needs dictate.
EDIT
Without the need for other includes or libraries just call:
clang matrix.s -mllvm -Wall -g -Wl,-pie -o matrix.out

Is there a gcc option to print the target triplet when cross-compiling?

gcc -dumpmachine is almost perfect, but it doesn't respect flags that affect the target. On the other hand, clang does:
$ gcc -dumpmachine
x86_64-unknown-linux-gnu
$ gcc -dumpmachine -m32
x86_64-unknown-linux-gnu
$ clang -dumpmachine
x86_64-unknown-linux-gnu
$ clang -dumpmachine -m32
i386-unknown-linux-gnu
Perhaps -print-multiarch is useful. According to the documentations, this option "display the target's normalized GNU triplet, used as a component in the library path".
In my box (x86_64) I get:
$ gcc -print-multiarch
x86_64-linux-gnu
$ gcc -print-multiarch -m32
i386-linux-gnu

Telling ld where to look for dependent shared libraries during compilation

I'm trying to crosscompile some libraries for an ARM processor, specifically:
DirectFB, which depends on libpng, which depends on zlib.
Libpng is linked against zlib, but since the paths on the build system don't match the paths on the target system, ld can't find the zlib that libpng is linked against during the compilation of DirectFB.
I've reduced the issue to the following example:
testb depends on libb, which depends on liba.
Build liba:
gcc -Wall -fPIC -c a.c
gcc -shared -Wl,-soname,liba.so.1 -o liba.so.1.0 a.o
ln -fs liba.so.1.0 liba.so.1
ln -fs liba.so.1 liba.so
Built testa:
gcc -Wall -I. -L. testa.c -la -o testa
LD_LIBRARY_PATH=. ./testa
a: 0
Build libb:
gcc -Wall -fPIC -I. -L. -c b.c -la
gcc -shared -Wl,-soname,libb.so.1 -o libb.so.1.0 b.o
ln -fs libb.so.1.0 libb.so.1
ln -fs libb.so.1 libb.so
So far, so good. However, building testb fails:
gcc -Wall -I. -L. testb.c -lb -o testb
Results in:
./libb.so: undefined reference to `a'
collect2: ld returned 1 exit status
make: *** [testb] Error 1
So ld can't find the definition of a in liba, even though libb is linked against liba, and both are in the current directory, which is being passed with "-L."
Running gcc with -v results in:
gcc -v -Wall -I. -L. testb.c -lb -o testb
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5.1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-I.' '-L.' '-o' 'testb' '-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1 -quiet -v -I. testb.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase testb.c -mtune=generic -march=i486 -auxbase testb -Wall -version -fstack-protector -o /tmp/ccqAkMFb.s
GNU C (Ubuntu 4.4.3-4ubuntu5.1) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128244
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
.
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include
/usr/lib/gcc/i486-linux-gnu/4.4.3/include-fixed
/usr/include
End of search list.
GNU C (Ubuntu 4.4.3-4ubuntu5.1) version 4.4.3 (i486-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128244
Compiler executable checksum: 2349e080d2b2f3f970047e63bbe98cb2
COLLECT_GCC_OPTIONS='-v' '-Wall' '-I.' '-L.' '-o' 'testb' '-mtune=generic' '-march=i486'
as -V -Qy -o /tmp/ccc6ux7S.o /tmp/ccqAkMFb.s
GNU assembler version 2.20.1 (i486-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.20.1-system.20100303
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../:/lib/:/usr/lib/:/usr/lib/i486-linux-gnu/
COLLECT_GCC_OPTIONS='-v' '-Wall' '-I.' '-L.' '-o' 'testb' '-mtune=generic' '-march=i486'
/usr/lib/gcc/i486-linux-gnu/4.4.3/collect2 --build-id --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o testb -z relro /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.4.3/crtbegin.o -L. -L/usr/lib/gcc/i486-linux-gnu/4.4.3 -L/usr/lib/gcc/i486-linux-gnu/4.4.3 -L/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.4.3/../../.. -L/usr/lib/i486-linux-gnu /tmp/ccc6ux7S.o -lb -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.4.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crtn.o
./libb.so: undefined reference to `a'
collect2: ld returned 1 exit status
make: *** [testb] Error 1
Setting LD_LIBRARY_PATH and/or LIBRARY_PATH to the current directory doesn't resolve the problem.
Compiling with -la works, but it shouldn't be necessary, since libb is linked against liba. For example, when linking against libpng in a native build environment (correct paths, library paths in ld.so.conf) doesn't require -lz.
Also, setting additional libs to link against is a pain, because I would have to patch the Makefiles for every compilation that depends on a lib that depends on another lib.
In summary, how do I tell ld where to look for dependent shared libraries during compilation?
My problem is similar to these two:
Cross-linking for ARM/QNX fails with indirect/transitive dependencies
How to resolve shared library linking during compilation( GCC )?
Neither suggests a solution which doesn't require the addition of -la, which in my opinion shouldn't be necessary.
Files used:
a.c:
int a() {
return 0;
}
liba.h:
#ifndef LIBA_H
#define LIBA_H
int a();
#endif
testa.c:
#include <stdio.h>
#include <liba.h>
int main() {
printf("a: %d\r\n", a());
return 0;
}
b.c:
#include <liba.h>
int b() {
return a();
}
libb.h:
#ifndef LIBB_H
#define LIBB_H
int b();
#endif
testb.c:
#include <stdio.h>
#include <libb.h>
int main() {
printf("b: %d\r\n", b());
return 0;
}
Makefile:
# Makefile for shared library test
all:
liba:
gcc -Wall -fPIC -c a.c
gcc -shared -Wl,-soname,liba.so.1 -o liba.so.1.0 a.o
ln -fs liba.so.1.0 liba.so.1
ln -fs liba.so.1 liba.so
testa: liba
gcc -Wall -I. -L. testa.c -la -o testa
runtesta: testa
LD_LIBRARY_PATH=. ./testa
libb: liba
gcc -Wall -fPIC -I. -L. -c b.c -la
gcc -shared -Wl,-soname,libb.so.1 -o libb.so.1.0 b.o
ln -fs libb.so.1.0 libb.so.1
ln -fs libb.so.1 libb.so
testb: libb
gcc -v -Wall -I. -L. testb.c -lb -o testb
runtestb: testb
LD_LIBRARY_PATH=. ./testb
clean:
# clean up
rm -rf *.o
rm -rf liba.s*
rm -rf libb.s*
rm -rf testa testb
You must add -la to linking phase of lb (second line below is essential):
$ gcc -Wall -fPIC -I. -L. -c b.c -la
$ gcc -L. -shared -o libb.so b.o -la
$ LD_LIBRARY_PATH=. gcc -Wall -I. -L. testb.c -lb -o testb
$ LD_LIBRARY_PATH=. ./testb
b: 0
Also -la on compilation isn't really required, I left it only because it was in your original example. Instead first line
$ gcc -Wall -fPIC -I. -L. -c b.c
will be enough.
Common rule is -- linker is guy, who need libraries, not compiler.

Resources