valgrind can be run using argument --gen-suppressions=yes (or e.g. --gen-suppressions=all). This helps generate the statements and their syntax to define the contents of a suppression file. That suppression file can be fed into valgrind the next time.
This is for instance useful to suppress those "Conditional jump or move depends on uninitialised value(s)" messages that are so often reported but not really a problem. I wish there was an easy way for valgrind to just not bother telling me about conditional jump issues, but it appears to be stern about having to tell me about it.
The cumbersome thing is that the output is printed on stdout. I have to then copy-paste those printed statements to the suppression file. Problem is that the program prints a whole lot of stuff to stdout as well.
So, can I tell valgrind to print those suppression statements to a suppression file?
To redirect valgrind output to a file use: --log-file=test.log. If you find the output is mixed with the application output then redirect valigrind output to separate file descriptor: --log-fd=9 9>>test.log.
Related
I want to change where in the elf file execution starts. For example I have a basic hello world program in a elf file. The actual code is located at an offset of 0x1000 bytes into the file. I want to move that code to, lets say, a 0x900 offset and modify the file so that it starts executing at 0x900. I know this sounds kinda useless but it does serve a purpose.
First you compile/assemble (clang/as/...) your program into a hello.o ELF object file. At this point, you would normally let the compiler driver finish the job and emit an ELF executable.
You can instead use the linker (lld/ld/...) and specify the entry point with --entry 0x900. You can also do this with a linker script. Note that if you do this, you have to handle a bunch of stuff that the compiler driver normally handles for you. The warning from the Oracle linker manual says:
When you invoke the link-editor directly, you have to supply every
object file and library required to create the intended output. The
link-editor makes no assumptions about the object modules or libraries
that you meant to use in creating the output.
Trying to do this and stumbled upon the -I option here: $ g++ -o version version.cpp -I/usr/local/qt4/include/QtCore -I/usr/local/qt4/include -L/usr/local/qt4/lib -lQtCore
I can't find any information about it
If you're looking for what -I does:
-I[/path/to/header-files]
Add search path to header files (.h) or (.hpp).
From https://caiorss.github.io/C-Cpp-Notes/compiler-flags-options.html
This pretty much just means that any #include statements you make to an external library (in your case qt) have to be referenced so that g++ knows where to look.
if my understanding is correct, question is about -i, not -L, I hope this helps:
-Idir Append directory dir to the list of directories searched for include files.
on this link
http://www.cs.virginia.edu/helpnet/Software_Development/compilers/g.html
g++ - GNU project C++ Compiler (v2 preliminary)
g++ [option | filename] ...
Capabilities
The C and C++ compilers are integrated. Both process input files through one or more of four stages: preprocessing, compilation, assembly, and linking.
C++ source files use one of the suffixes `.C', `.cc', or `.cxx'.
Options
There are many command-line options, including options to control details of optimization, warnings, and code generation, which are common to both gcc and g++. For full information on all options, see gcc(1).
Options must be separate: -dr' is quite different from- d -r '.
-c Compile or assemble the source files, but do not link. The compiler output is an object file corresponding to each source file.
-Dmacro Define macro macro with the string `1' as its definition.
-Dmacro=defn Define macro as defn
-E Stop after the preprocessing stage; do not run the compiler proper. The output is preprocessed source code, which is sent to the standard output.
- g Produce debugging information in the operating system's native format (for DBX or SDB or DWARF). GDB also can work with this debugging information. On most systems that use DBX format, `-g' enables use of extra debugging information that only GDB can use.
Unlike most other C compilers, GNU CC allows you to use ` -g' with `-O'. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs.
-Idir Append directory dir to the list of directories searched for include files.
-llibrary Use the library named library when linking. (C++ programs often require `-lg++' for successful linking.)
-O Optimize. Optimizing compilation takes somewhat more time, and a lot more memory for a large function.
Without `-O', the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the function and get exactly the results you would expect from the source code.
Without `-O', only variables declared register are allocated in registers. The resulting compiled code is a little worse than produced by PCC without `-O'.
With `-O', the compiler tries to reduce code size and execution time.
-o file Place output in file file.
i'm just learning how to use GDB.
I'm trying to set a breakpoint for an external binary that is called by my program. I do not have the source of the other binary, so I can't compile it with the -g option.
Both my file and the other (a Framework) are written in Objective-C.
I managed to find the address of the line where I want to set my break, but of course GDB so not allow to use that, since I'm working with my file.
How can I tell GDB to set a breakpoint on that binary file, on that address?
To break at a specific address you can use:
break *0x12345
The "*" tells gdb to interpret the remainder of the "linespec" (see the manual) as an expression.
Often, even without debug info, you can still set breakpoints by name. This will work as long as there are "linker" symbols of whatever flavor in the library, and as long as you know the linkage name.
Using the different Valgrind tools for profiling and debugging individual programs is easy. I am working on a big project with lot of modules and packages. (for Router SoC).
On Building the model, how do I use Valgrind for debugging during compilation of the entire model? Should I include Valgrind in the makefile (Because I don't want to run Valgrind separately for every individual file)? All I want is during the compilation of the entire big model, I want Valgrind's output log files for every individual C program?
You may try something like valgrind --trace-children=yes --log-file="log.%p" the-whole-shebang. The %p is substituted for pid. You can throw in some --trace-children-skip or --trace-children-skip-by-arg options if you wish to skip certain uninteresting parts. See valgrind man page for details. Or perhaps combination of --log-socket and valgrind-listener? It would be easier to filter output that way if you are up for little scripting.
I am writing in fortran and compiling using the g95 compiler.
I need to have a log file output to a DLL i am writing, that is currently linking and running with the master program, but producing incorrect results. I don't know much about FORTRAN, but i did get the following code to produce output in an EXE i compiled:
OPEN(UNIT=3, FILE='LOG.txt', STATUS='NEW')
WRITE(3,*) "the gospel of PTP is bestowed upon the file."
CLOSE(3)
this works in a stand alone EXE, when i run it, it produces a file with the string inside. But when i try to include it in the DLL i am working on, it crashes everything. when i comment it back out, everything runs and works again, but obviously doesn't produce the desired output.
Any ideas? Any FORTRAN or g95 people?
A guess which might help, or might not, I have rarely used Fortran DLLs to write anything directly:
To where do you expect the DLL to write the file 'LOG.txt' ? Is it perhaps trying to write into a location it is forbidden to write to ? Why that would crash your program I'm not very sure, but it's something for you to check. I expect that you ran the EXE version of your code from one of your user directories.
And, a comment:
In general avoid single-digit unit numbers in Fortran. Most o/s use them for stdout, stderr, etc, and while there are usual assignments (eg stdout is usually 5 I think, and stderr 6) these are not defined in the Fortran standard and compiler-writers are free to use unit numbers as they see fit.