Determining control flow of GCC - gcc

I want to understand how GCC works, therefore would like to know which functions are executed in which sequence. For me, it is hard to understand it by only looking at the GCC source code.
Is there any tool to track the internal functions that are being called by GCC when compiling a c file?

You can use debugger to execute gcc step-by-step, but gcc it is quite complicated piece of software.

Related

GDB or Radare2?

Should I use GDB or Radare2 for reversing an executable(I am a beginner)?
I try to programming in C and I got a SegFault. I want to Reverse Engineer it to get experience in Assembly and see where I get the SegFault.
For debugging an executable you built from source yourself, GDB is intended as a debugger. You can use layout reg to get a disassembly + registers view which can help understanding segfaults, if looking at C variables didn't help.
Debug info from compiling with gcc -g means you don't need to reverse-engineer anything, just use a normal debugger. But to get experience in asm, using a debugger both ways (source view and asm view) can help you understand how the compiler used certain asm instructions to implement each C statement. So you definitely want a debugger that can take advantage of debug info. There are some GUI GDB front-ends, like https://www.gdbgui.com that can be easier to use than command-line GDB.
But see also How to remove "noise" from GCC/clang assembly output? for more about seeing how C compiles to asm.
I haven't used radare2. I assume it has features that are good for intentionally-obfuscated executables without source, which is the opposite of what you have from compiling your own C programs with a normal compiler.
I would recommend Radare2 because it's clearer than GDB and easier for beginners ;)

What it takes to make OpenACC/OpenMP4.0 offloading to nvidia/mic work om GCC?

I am trying to understand how exactly I can use OpenACC to offload computation to my nvidia GPU on GCC 5.3. The more I google things the more confused I become. All the guides I find, they involve recompiling the entire gcc along with two libs called nvptx-tools and nvptx-newlib. Other sources say that OpenACC is part of GOMP library. Other sources say that the development for OpenACC support will continue only on GCC 6.x. Also I have read that support for OpenACC is in the main brunch of GCC. However if I compile a program with -fopenacc and -foffload=nvptx-non is just wont work. Can someone explain to me what exactly it takes to compiler and run OpenACC code with gcc 5.3+?
Why some guides seem to require (re)compilation of nvptx-tools, nvptx-newlib, and GCC, if, as some internet sources say, OpenACC support is part of GCC's main branch?
What is the role of the GOMP library in all this?
Is it true that development for OpenACC support will only be happening for GCC 6+ from now on?
When OpenACC support matures, is it the goal to enable it in a similar way we enable OpenMP (i.e., by just adding a couple of compiler flags)?
Can someone also provide answers to all the above after replacing "OpenACC" with "OpenMP 4.0 GPU/MIC offload capability"?
Thanks in advance
The link below contains a script that will compile gcc for OpenACC support.
https://github.com/olcf/OLCFHack15/blob/master/GCC5OffloadTest/auto-gcc5-offload-openacc-build-install.sh
OpenACC is part of GCC's main branch now, but there are some points to note. Even if there are libraries that are part of gcc, when you compile gcc, you have to specify which libraries to compile. Not all of them will be compiled by default. For OpenACC there's an additional problem. Since, NVIDIA drivers are not open source, GCC cannot compile OpenACC directly to binaries. It needs to compile OpenACC to the intermediate NVPTX instructions which the Nvidia runtime will handle. Therefore you also need to install nvptx libs.
GOMP library is the intermediate library that handles both OpenMP and OpenACC
Yes, I think OpenACC development will only be happening in GCC 6, but it may still be backported to GCC 5. But your best best would be to use GCC 6.
While I cannot comment on what GCC developers decide to do, I think in the first point I have already stated what the problems are. Unless NVIDIA make their drivers open source, I think an extra step will always be necessary.
I believe right now OpenMP is planned only for CPU's and MIC. I believe OpenMP support for both will probably become default behavior. I am not sure whether OpenMP targeting NVIDIA GPU's are immediately part of their target, but since GCC is using GOMP for both OpenMP and OpenACC, I believe eventually they might be able to do it. Also, GCC is also targeting HSA using OpenMP, so basically AMD APU's. I am not sure whether AMD GPU's will work the same way, but it maybe possible. Since, AMD is making their drivers open source, I believe they maybe easier to integrate into default behavior.

Why is clang used for autocompletion in vim and emacs?

Why isn't gcc used for that? Where is the difference between them and why does almost any autocomplete plugin require clang?
The simple answer is that clang was designed to support completion while gcc was not.
Clang has a command line option that prints out possible completions at a given point in a source file, which makes it easy to use in scripts: Just shell out to clang, parse its output, done. Gcc has nothing comparable.
As for why, see this list of differences between gcc and clang:
[...]
Clang is designed as an API from its inception, allowing it to be reused by source analysis tools, refactoring, IDEs (etc) as well as for code generation. GCC is built as a monolithic static compiler, which makes it extremely difficult to use as an API and integrate into other tools. Further, its historic design and current policy makes it difficult to decouple the front-end from the rest of the compiler.

debugging ex_bad_access with gdb in c++

I'm compiling code from the command line with g++ on Mac OSX and have an error when I run my code that results in an EXC_BAD_ACCESS
I've seen that the most helpful way to debug this kind of error is with Zombie objects that don't deallocate when released and then complain when code tries to release them.
However, it seems that NSZombie options are available in Xcode/Objective C.
So my question is there any way to use this functionality/equivalent in programs simply compiled code like
g++ file1.cpp -g -o executable
debugged with
gdb executable
Thanks.
Zombie objects are a concept of Objective-C, not C++, and relate to reference counting issues, which C++ doesn't use (unless you count smart pointers and Enabling Zombies won't help you with that anyway).
So, to answer your question; No, there is no way to use that functionality.
If you want to find the issue then you'll need to use a debugger.

How to call a C compiler through library instead of via system call?

In a project that I have been asked to revise, there is a segment of code that is tantamount to just generating a set of assembly instructions, writing them to a file, and then compiling it with the gcc compiler.
My question is, is there any way to link in a library that would do this work for me via an exposed API call? I need 1-1 equivalence to the following command:
gcc -m32 -c -o objfile generated_asm.asm -masm=intel
You cannot do exactly that. You might fork the GCC compilation command. It is probably operating system specific, I'm supposing you are on Linux (or some other POSIX system).
However, there are alternatives:
using asmjit to generate x86 machine code in memory
using tinycc and its libtcc library (which can compile a string containing C or asm code; beware, the compiled machine code is slow since unoptimized)
using a JIT library like libjit, or LLVM, or GNU lightning
coding in a metaprogramming language like Common Lisp (e.g. SBCL) or MetaOcaml
Also, you could simply fork a GCC compilation of some generated C file genfoo.c into a shared object (gcc -Wall -O -fPIC genfoo.c -shared -o genfoo.so) then dynamically loading with dlopen the ./genfoo.so file (see also this)
PS. Next GCC 5.0 release will have a JIT library (libgccjit).
Generally, no, because Unix insisted we think of everything as text strings (including command lines). And we all accepted Unix.
Technically GCC is just giant subroutine with a big parameter list.
The fact that you get to it though a text string is a stupid design decision we all made by dumping Multics and/or LISP machines. On these systems, subroutines (even big ones) are all called natively, and thus really compose.
With Multics, the compiler is (well was, Multics is pretty dead) a subroutine you can call. (Yes, there was a command line interface that could also make that call, so people could invoke it).

Resources