Using command clang -### a.c can output the commands that clang a.c calls.
For me, it outputs followings on my screen(focus on last three lines):
clang version 1.0 (https://llvm.org/svn/llvm-project/cfe/branches/release_26 exported)
Target: x86_64-unknown-linux-gnu
Thread model: posix
"/usr/local/bin/llvm+clang-2.6-x86_64-linux/bin/../libexec/clang-cc" "-triple" "x86_64-unknown-linux-gnu" "-S" "-disable-free" "-main-file-name" "a.c" "--relocation-model" "static" "--disable-fp-elim" "--unwind-tables=1" "--mcpu=x86-64" "--fmath-errno=1" "-fdiagnostics-show-option" "-o" "/tmp/cc-yffqSv.s" "-x" "c" "a.c"
"/usr/bin/gcc" "-c" "-m64" "-o" "/tmp/cc-pa2Qo4.o" "-x" "assembler" "/tmp/cc-yffqSv.s"
"/usr/bin/gcc" "-m64" "-o" "a.out" "/tmp/cc-pa2Qo4.o"
In the line: /usr/local/bin/llvm+clang-2.6-x86_64-linux/bin/../libexec/clang-cc" "-triple" "x86 ......, it shows that the command clang called this: /libexec/clang-cc.
What does it(file "libexec/clang-cc") do?
And there is another question related I desired to ask:
Whether or not: command clang uses the front end of the project "clang", and the back end of "gcc"?
Because I find the last two line of code above called "/usr/bin/gcc".
I have search this for hours, can you help me?
Thanks in advance.
You seem to be using quite an old version of Clang. You might want to try a newer one.
clang-cc is the clang C compiler, which converts a C program to assembly language. [Note 1]. Depending on version and target, it may also be able to directly produce an object file. See the -integrated-as command-line flag.
If your version of Clang does not have an assembler for your target architecture, the clang driver will try to use the system assembler (and linker). On some systems, these will be part of Gcc, although there are other options.
Notes
Clang actually first compiles C (or other C-like languages) into platform-neutral LLVM Intermediate Representation (IR), and then uses the LLVM library to convert that into optimised platform-specific assembler code. These two parts are what are generally referred to as the Clang "front-end" (C⇒LLVM) and "back-end" (LLVM⇒Assembler). These are not separate programs
What does it(file "libexec/clang-cc") do?
Its output "-o" "/tmp/cc-yffqSv.s" suggests it outputs assembly.
and the back end of "gcc"?
The last two lines with gcc invocations are:
Generate an object file from the assembly.
Link object files into a.out.
Related
I'm writing firmware using an older C compiler called HC12. Currently I use GNU Make for the build system. I'm hoping to start using CMake, but ran into an issue:
The compiler does not support some standard C compiler syntax, namely the "-o" flag.
I've made a custom toolchain file and added all my c flags, but CMake seems to implicitly add the "-o" to compile source files, in the generated GNU Makefiles.
The HC12 compiler allows me to use -objn="name_of_file" to specify the output filename.
My question: Is there a way to get CMake to stop putting the implicit "-o" so that I can use this compiler?
I know there is a GCC port for this processor, but changing compilers at this point isn't an option.
You could take a file like the Modules/Compiler/ti.cmake as a reference and create one for your HC12 compiler, and also change these macros defined there:
# the input file options from TI, change to what your compiler needs
# They are used below in the command where ${lang} is either C, CXX or ASM
set(__COMPILER_HC12C_SOURCE_FLAG_C "--c_file")
set(__COMPILER_HC12C_SOURCE_FLAG_CXX "--cpp_file")
set(__COMPILER_HC12C_SOURCE_FLAG_ASM "--asm_file")
# add output file option
set(__COMPILER_HC12C_OUTPUT_FLAG_C "--objn")
macro(__compiler_HC12C lang)
# ...
set(CMAKE_${lang}_COMPILE_OBJECT "<CMAKE_${lang}_COMPILER> --compile_only ${__COMPILER_HC12C_SOURCE_FLAG_${lang}}=<SOURCE> <DEFINES> <INCLUDES> <FLAGS> ${__COMPILER_HC12C_OUTPUT_FLAG_${lang}}=<OBJECT>")
# --------------------------------------- ---------------------------------------
# ...
endmacro()
Hope, this will help.
I have a setup like this:
GDB from "GNU Arm Embedded Toolchain" 10.3-2021.10
GDB server from "Segger JLink" 7.54d
JLink Ultra+ connected to my PC and my embedded device
Arm Compiler 6.15
I'm having problems stepping into a certain function from a C module (let's call it "F1"). When trying, I get the error message
Single stepping until exit from function "F1", which has no line number information.
If I use Segger Ozone, with the same .elf file, stepping into "F1" works fine.
I've tried to narrow down the problem and have the following observations:
A single line of code from the C module holding "F1" makes the difference. If I remove this line, it works. This line is a simple incrementation (++) of a static uint32_t variable and it is in a separate function (i.e. not "F1").
If I don't link with "--inline" option, it stops working - even with the "fix" in (1)
All source files (a mix of C and C++ files) are compiled with -g option.
I may try to reproduce it in a much smaller context which I could share here but until then, I'm hoping for some hints.
Anything is appreciated.
[Update 2021-11-10] Tried with older/newer versions of "GNU Arm Embedded Toolchain" as well as "Segger JLink". Same problem.
[Update 2021-11-10] Compiler/linker command used:
armclang -g --target=arm-arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=soft -MMD -Werror -D__STDC_LIMIT_MACROS -I<my_include_paths>
armlink --inline --info=sizes --info=veneers --info=unused --info=totals --map --symbols --scatter=<my_scatter_file> --list=list.txt
I was using Fortran g77 and experienced this problem:
c this program calculates runoff and sediment
1 2
Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2)
Also, the compiler can recognized only .for file extension, not .f.
Does anyone know, where is the problem? I downloaded it from http://www.cse.yorku.ca/~roumani/fortran/ftn.htm.
The compiler is not recognizing that statement as a comment. As a comment it should ignore the line but it is trying parse it. Are you sure that the "C" is in the first column?
Why are you using g77? It hasn't been supported for years. gfortran is the current GNU Fortran compiler. It can compile FORTRAN 77, Fortran 90, 95 and portions of 2003 and 2008.
EDIT: Perhaps its wants an upper-case "C".
The page you have linked to states that the f2exe wrapper passes -ffree-form to the compiler:
Compilation Command
The above f2exe command is just a batch file that invokes g77, the "real" compilation command. The command:
g77 -ffree-form prog.for -oprog.exe
directs the compiler to compile the file prog.for and stores the output in the file prog.exe. The -ffree-form switch indicates free-form style (remove it if you are using the old style).
In free-form Fortran the only allowed comment format is that of a line starting with !. As a matter of fact, this is also written on the same page directly under the above text:
Comments
In free-form style, use ! for both full-line and in-line comments. In the old style, use a "C" in column-1.
If you are not using the provided f2exe wrapper, don't pass -ffree-form option when compiling fixed-form FORTRAN 77 code.
I'll assume you want to stick with this compiler.
As noted above, the problems you have come from using the F2EXE batch file, which is not very useful: first it automatically adds ".for" to the file name, so you can't compile ".f" files, and it assumes free-form syntax, which is unusual when programming in Fortran 77 (and if you want Fortran 90, find another compiler, other answers give you links).
Now, suppose you have written a program myprogram.f, and you are in a Windows command line, in the same directory where the program resides (use "cd C:\mydirectory" for example, to change)
You will compile with
g77 myprogram.f
If you use SLATEC, you use
g77 myprogram.f -lslatec
If you want to specify a name for your .exe file (default is a.exe), you write
g77 myprogram.f -o myprogram.exe
There are other useful options
g77 -O2 myprogram.f to optimize (within g77 2.95 limitations)
g77 -Wall myprogram.f to enable all compiler warnings, very useful
to find errors in your code
g77 -c myprogram.f to only compile (you get a .o file), this is
useful to compile functions and subroutines, to
later build a static library (.a file), like
libslatec.a which is given with the compiler
And to build a library, using ar.exe:
ar cru mylib.a myfunc1.o myfnuc2.o ...
Then you can use is with
g77 myprogram.f mylib.a
G77 runs in command line under Windows. You write programs in a text editor.
Notepad++ is fairly good and its free. See http://notepad-plus-plus.org/
If you have problems with compilation, maybe it comes from environment variables, so here are some precisions. You have to tell Windows where to find the G77 compiler (g77.exe).
You can follow instructions on the site where you downloaded it to change Windows' environment variables PATH and LIBRARY_PATH. It needs you install the compiler in the C:\F directory : that is, you will have C:\F\G77\bin, etc.
Slight modification to the instructions on that page :
You should set PATH to C:\F\G77\bin
And LIBRARY_PATH to C:\F\G77\lib;C:\F\SLATEC\lib
This modification to LIBRARY_PATH allows you to compile with SLATEC simply with "-lslatec" as above.
A note about the compiler. It's G77, also know as GNU Fortran 77. An old compiler, integrated with the well known GCC suite until GCC 3.4.6 (we are at GCC 4.7.2 now). And the compiler you downloaded is for version GCC 2.95.
It's a good Fortran 77 compiler, but it's not very well optimized, and of course, you don't get any support for new processor features such as Intel SSE.
Modern Fortran compilers can still understand most if not all of Fortran 77, plus all the newer features of Fortran 90 and newer standards, which are extremely useful.
It may also be interesting to know there is another place to download the same compiler (eccept there is no SLATEC), just in case the page gets destroyed :
http://www.mbr-pwrc.usgs.gov/software/g77.html
I am calling fortran 90 code from a c code. There is a main() (in c) that calls a wrapper function in the same file, that calls a fortran subroutine (actually in a liblibrary.a). I am working on linux. Now, I'm using gdb to debug the executable, but it cannot find the main.c file. I added the working directory using
directory /my/working/directory
but still it says there is no file named main.c
If I type list inside gdb it shows me a piece of fortran code. If I type show language, it says The current source language is auto; currently c.
If I run the executable and then I interrupt it and look to the stack it will show me the c-functions I am calling, but it will not state the source file, that instead will state for the fortran subroutine and function.
I am trying to investigate if I am passing the variables correctly from c to fortran and backwards, I suspect I am not.
The same thing happens in idb, more or less. when I try to put a break in main.c, it says not found. I compiled the fortran code with these flags:
-g -O0 -check bounds -warn all -traceback -align all -align rec8byte
and the c-code with:
-g -O0 -Wall
All suggestions are welcome.
Hello you need additional flag to put debug info into your executable.
Here is manual for intel compiler:
http://cache-www.intel.com/cd/00/00/34/75/347599_347599.pdf
Please try -debug full as on page 35 written.
A third party provided me a static lib (.a) to link with on solaris station.
I tried to compile with sunpro, and failed at link step.
I suppose the issue is coming from the compiler I use (gcc instead?) or simply its version (as the std lib provided by the compiler could change from the version expected by the library AFAIK it could leads to errors at link step).
How could I know which compiler was used to generate this lib? Is there some tools doing that? Some option in sunpro/gcc or whatever?
As an hint: I've read some time ago that compilers use different mangling conventions when generating object files (true?). Still, "nm --demangle" command line prints me well all function names from debug symbols in this static lib. How does it work ? If my assumption is ok, nm does have a way to resolve which convention is in use in a static library, isn't it? Or is it simply meaning that lib was generated by GNU gcc, as nm is a part of GNU binutils?
I am not close to my workstation so I can't copy & paste error output from the linker (not for the moment but I could copy them in a further edit)
Extract the object files from the archive then run the strings command on some of them (first on the smaller ones since there'd be less noise to sift through). Many compilers insert ASCII signatures in the object files.
For example, the following meaningless source file, foo.c:
extern void blah();
when compiled on my Fedora 10 machine into foo.o via gcc -c -o foo.o foo.c results in a 647 byte foo.o object file. Running strings on foo.o results in
GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7)
.symtab
.strtab
.shstrtab
.text
.data
.bss
.comment
.note.GNU-stack
foo.c
which makes it clear the compiler was GCC. Even if I'd compiled it with -fno-ident, the .GNU-stack note ELF section would have still been present.
You can extract the object files using the ar utility, or using Midnight Commander (which integrates ar), or you can simply run strings on the archive (which might give you more noise and be less relevant, but would still help.)
I tend to use the strings program (with the '-a' option, or my own variant where the '-a' behaviour is standard) and look for the tell-tale signs. For example, in one of my own libraries, I find:
/work1/gcc/v4.2.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.2.3/include
/work1/gcc/v4.3.0/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.0/include
/work1/gcc/v4.3.1/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.1/include
/work1/gcc/v4.3.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.3/include
That suggests that the code in the library has been compiled with a variety of versions of GCC over a period of years (actually, I'm quite startled to find so many versions in a single library).
Another library contains:
cg: Sun Compiler Common 11 Patch 120760-06 2006/05/26
acomp: Sun C 5.8 Patch 121015-02 2006/03/29
iropt: Sun Compiler Common 11 Patch 120760-06 2006/05/26
/compilers/v11/SUNWspro/prod/bin/cc -O -v -Xa -xarch=v9 ...
So, there are usually fingerprints in the object files indicating which compiler was used. But you have to know how to look for them.
Is the library supposed to be a C or C++ library?
If it is a C library then name mangling can not be the problem, as there is none in C. It could be however in a wrong format. Unices used to have libraries in the a.out format but almost all newer versions switched to more powerful formats like ELF.
If it is a C++ library then name mangling can be an issue. Most compilers embed some symbols that are compiler specific into the code, so if you have a tool like nm to list the symbols you can hopefully deduce from what compiler it came.
For example g++ creates a symbol
__gxx_personality_v0
in it's libraries
You can try the unix utility file:
file foo.a