I just took a look to the gcc-arm-none-eabi compiler binaries which are listed bellow but I really do not know all the used abbreviations. I would like to know which binary is the preprocessor, the linker, the compiler and so on ...
$ ls /opt/gcc-arm-none-eabi-5_4-2016q3/bin/
arm-none-eabi-addr2line
arm-none-eabi-ar
arm-none-eabi-as
arm-none-eabi-c++
arm-none-eabi-c++filt
arm-none-eabi-cpp
arm-none-eabi-elfedit
arm-none-eabi-g++
arm-none-eabi-gcc
arm-none-eabi-gcc-5.4.1
arm-none-eabi-gcc-ar
arm-none-eabi-gcc-nm
arm-none-eabi-gcc-ranlib
arm-none-eabi-gcov
arm-none-eabi-gcov-tool
arm-none-eabi-gdb
arm-none-eabi-gdb-py
arm-none-eabi-gprof
arm-none-eabi-ld
arm-none-eabi-ld.bfd
arm-none-eabi-nm
arm-none-eabi-objcopy
arm-none-eabi-objdump
arm-none-eabi-ranlib
arm-none-eabi-readelf
arm-none-eabi-size
arm-none-eabi-strings
arm-none-eabi-strip
I just can guess: gcc is the compiler? ld is the linker?
What is the exact purpose of all these binaries?
The leading 'arm-none-eabi' is the type of compiler. This is known as the tuple and is specified as a configure 'prefix'. Many of the binaries may be links or short wrapper scripts that call another binary (gcc). Also some of the names are just in case you have existing system binaries with the same name or multiple gcc installs.
You can find this information by running a man command on the program name. Briefly,
addr2line - convert an address (hex) to a code line number.
ar - a static library (or archive) tool.
as - an assembler
c++ - the C++ front-end
c++filt - convert a mangled name to function with prototypes.
cpp - the preprocessor only.
elfedit - elf header manipulation.
g++ - C++ with gnu extensions.
gcc - standard binary (given options can do the same as wrappers).
gcc-5.4.1 - full name for system with multiple GCC installs.
gcc-ar - rename in case of multiple 'ar'.
gcc-nm - rename in case of multiple 'nm'.
gcc-ranlib - rename in case of multiple 'ranlib'.
gcov - code coverage
gcov-tool - code coverage
gdb - the debugger
gdb-py - more minimal debugger
gprof - call graph/profiler.
ld - the linker (most likely gold).
ld.bfd - an older style linker with a few more features; MUCH slower for large C++ projects.
nm - display 'names' in a binary.
objcopy - manipulate a binary (sections).
objdump - information on a binary.
ranlib - generate a library index.
readelf - information on ELF binaries.
size - program section sizes
strings - dump all strings in a binary.
strip - remove debug information from a binary.
As a concept, the name 'gcc-ar' and 'ar' are physically the same thing. However, another 'ar' may exist in the path (a Solaris, or other Unix system) and the 'gcc-ar' name can be used to get the gcc specific 'ar'; all the 'gcc-XXX' things are for this use case.
Related
In gcc we have -x option that use to specify how to treat source file.
For example suppose we have a csourcecode file without any extension like .c.
In gcc simply using -x c before express csourcecode force compiler to use it as valid c source code.
gcc -x c csourcecode -o out
Is there any similar option for gfortran?
From the helpful gcc manual: [Note 1]
You can specify the input language explicitly with the -x option:
-x language
Specify explicitly the language for the following input files
(rather than letting the compiler choose a default based on the
file name suffix). This option applies to all following input
files until the next -x option. Possible values for language
are:
(snip)
f77 f77-cpp-input f95 f95-cpp-input
If you're using a Unix-y system and you took the precaution of installing the gcc documentation package (apt-get install gcc-doc on debian/ubuntu-like systems), then you could have found that information directly by typing
info gcc --index-search=x
because the GCC info files are index by option name. Most of the time you don't need to type --index-search=; info gcc x would suffice.
Notes:
In case it's not obvious, gfortran is just another front-end for the Gnu compiler collection ("gcc" for short), and accepts any options that would be accepted by the gcc command.
I write NASM (netwide assembler) program and for some reasons I needed to use some functions written in C. So, I tried to link compiled C object files with compiled Assembly objects using ld link editor. I did it by this way :
ld -m elf_x86_64 -lc --dynamic-linker=/lib64/ld-linux-x86-64.so.2 object_files -o program.
And it didn't want to link and work long enough until I picked up the necessary parameters. Now this works as expected with this parameter set. But I don't understand the meaning of -lc and --dynamic-linker=/lib64/ld-linux-x86-64.so.2. What do they do ?
-lc - link c standard library
--dynamic-linker=/lib64/ld-linux-x86-64.so.2. - set the program loader. Linux ELF binaries have a field for this.
Afaik the latter is needed even for static binaries, anything other will confuse the loader, and it won't execute.
man ld lists its parameters.
Are these two commands on linux:
objcopy --only-keep-debug foo foo.dbg
objcopy --add-gnu-debuglink=foo.dbg foo
equivalent to below on mac
dsymutil <binary> -o <binary>.dSYM
Equivalent in the sense that,
It creates a standalone debug info file.
It create a link between the executable and debug info file.
Then for stripping
is the commands on linux:
objcopy --strip-debug foo
OR
strip -g <binary>
equivalent to below on mac
strip -S <binary>
The --only-keep-debug part of the objcopy does functionally the same thing as dsymutil.
There isn't any tool to record the binary location in the dSYM. Rather the dSYM & the binary share a common UUID, and clients that want to find symbol files use the DebugSymbols framework, which uses various tricks (e.g. a Spotlight importer, search paths, a "dSYM finding external script", etc) to find the separate debug file. So there isn't a need for an equivalent to --add-gnu-debuglink.
The mac version of strip -S does strip debug information the same way that the binutils version does. The difference is that strip -S on OS X won't actually decrease the size of the binary much. On OS X, the debug information is always kept out of the executable - residing either in the .o files or in the dSYM. The executable only has a small "debug map" that tells lldb or dsymutil how to link the dwarf from the .o files. strip -S only has to remove the debug map.
I would like to create a symbol definition table to be used in a separate application during linking. ARM's armlink linker has the following flag but I'm using arm-eabi:
--symdefs=filename
The GNU objcopy utility has an option --extract-symbol that may do what you want. It generates an object file with only symbol data - no actual code or data.
It is specifically intended to generate a .sym file for use in the VxWorks RTOS which has a command shell and dynamic linker/loader that uses this information. It is also used by the VxWorks host shell and source-level debugger.
The binutils nm utility on the other hand generates output very similar to armlink's --symdefs which you might easily post-process into exactly the form you need.
-Wl,-Map -Wl,mapfile -Wl,--cref
added to the final gcc (link) command line should do the trick.
This the correct answer from arm gnu launchpad:
Do you intend to load the symdef file with the GNU toolchain or with armcc one? If the former I think using nm on the object file and then linking with -R <filename> would work. So you would do arm-none-eabi-nm -D ./prog > ./prog.defsym after linking prog and then arm-none-eabi-gcc -Wl,-R,./prog.defsym when you want to use this.
Here are a couple of ways to use functions from a static library, built with ar (i.e. libSOMTEHING.a):
ld -o result myapp.o -Lpath/to/library -lname
ld -o result myapp.o path/to/library/libname.a
Since we omit any dynamic libraries from the command line, this should build a static executable.
What are the differences? For example, are the whole libraries linked in the executable, or just the needed functions? In the second example, does switching the places of the lib and the object file matter?
(PS: some non-GNU ld linkers require all options like -o to be before the first non-option filename, in which case they'd only accept -L... -lname before myapp.o)
In the first line, a search for a dynamic library (libname.so) occurs before the static library (libname.a) within a directory. Also, the standard lib path is also searched for libname.*, not just /path/to/library.
From "man ld"
On systems which support shared libraries, ld may also search for
files other than libnamespec.a. Specifically, on ELF and SunOS
systems, ld will search a directory for a library called
libnamespec.so before searching for one called libnamespec.a. (By
convention, a ".so" extension indicates a shared library.)
The second line forces the linker to use the static library at path/to/lib.
If there is no dynamic library built (libname.so), and the only library available is path/to/library/libname.a, then the two lines will produce the same "result" binary.