I know gcc produces colored output for the error messages. Does a similar feature exist in ifort as well ?
This is done by external tools which are placed on top of gcc so that they can process output and colorize it (example: colorgcc). You could take a look at it, which is written in perl, and see if it's easy to adapt to fortan output errors..
Related
I am running gdb 10.1.90.20210103-git and gcc/g++ 10.2.1 20210110 on x86-64 Debian 11. My IDE is Codelite, which uses the manual rather than the machine interface to gdb, and enables me to type commands directly to gdb, and see the response (potentially copying the response to the clipboard). This when the inferior is paused after hitting a breakpoiunt, via the gdb console, which is in Codelite's Debugger > Output pane.
I was able to use the instructions at: https://sourceware.org/gdb/current/onlinedocs/gdb#Compiling-and-Injecting-Code "Compiling and injecting code in GDB" to compile simple C code and make it run in the environment of the halted inferior. For instance: compile code blah++; increments a local variable int in the inferior, which I can see via the Locals or Watch panes.
The compile file command worked fine as long as I specified the absolute path of the source file.
I was unable to see console output (to the inferior's or gdb's console) for a simple printf() statement: `printf("xxx");' because the code would not compile if there was such a line
Despite using set debug compile and set debug compile-cplus-types and checking these are set with the show versions of these, I get no error messages or acknowledgements regarding whatever I try to compile.
The blah variable is an integer, which is accessible through C code and so gcc. The ability to increment this was the only indication that my code had compiled and run.
I could not get any responses to set/show compile gcc so I am presumably compiling with gcc. I did give the command set compile gcc /usr/bin/x86_64-linux-gnu-cpp-10, but there was still no response from show compile gcc or any change in the C-only behaviour.
I could not compile the file if it contained a C++ line which incremented a data member of a class object in an vector of such objects. Nor could I compile my code if it contained C++ code such as: #include <fstream> and/or std::fstream oFile;.
The gdb documentation mentioned above is general, but does have C examples.
Is it possible to compile C++ code under gdb, injecting it into the environment of the paused inferior, with any version of gdb and gcc?
I am keen to use this C++ code injection facility, if it exists, for dumping the contents of large, complex, data structures to files and and to modify some elements of same to aid debugging.
Summary: GDB's C++ compilation and injection system does not work for me, and it is reported to be buggy or non-functional. I only tested this compile command with single lines of C code, but it worked fine for these. I was able to run my function, which writes a text dump file containing the values of a vector of class objects' data members, while the inferior was paused after a breakpoint, by including it in a source file and calling it with GDB's print or call commands, giving it the required input argument of the name of the vector to dump.
I haven't tried using GDB on its own, but at present I have no reason to believe that Codelite is interfering with my ability to communicate with GDB via Codelite's "Debugger > Output" console.
I wrote to the GDB Developer list and received what I assume is a well informed reply. I was told that in my respondent's experience "the C++ plugin isn't very functional. It seems to have some bugs and crash pretty frequently as well. Also, it seems like nobody is actively working on it." This is consistent with my experience to date.
Perhaps later versions of GDB would work better. However, there has been minimal change to the library https://github.com/gcc-mirror/gcc/commits/master/libcc1/libcp1.cc since 2017, and I could find no indication of new work on C++ compilation and injection in https://www.sourceware.org/gdb/news/ since the announcement of its introduction:
GDB 8.3.1 was released on 2019-09-20, with: "Experimental support for compilation and injection of C++ source code into the inferior (requires GCC 7.1 or higher, built with libcp1.so)."
It is possible that my problem is related to not having this library. I do have the C equivalent: /usr/lib/x86_64-linux-gnu/libcc1.so.o. I could find no such library in a Debian package. It is possible I could get this going by compiling the latest GCC/G++ and GDB, but that is pretty daunting, involving installing later standard libraries than my current Debian installation has, while making those and the newer G++ and GDB available for Codelite sessions, but not interfering with other software on machine which needs the older compilation system.
The respondent suggested that instead of compiling and injecting fresh code in the middle of a debugging session, I could write it as a library, and run it by using the compile command, on a purely C piece of code which would call it. However, for my purposes, the function needs to be passed one or more C++ constructs, and any code which called a C++ function would be C++ code and so, presumably, not be compiled by GDB.
For my immediate purpose of doing text dumps of large vectors of class objects' data members, I was able to succeed by writing such a function in an existing source file, which also contains the functions I am debugging. Then I could call it with GDB's print or call commands. I imagine this would work if the debugging function was in any other linked source file, or in a linked library. (Perhaps there is a way of writing such a library, compiling and linking it while the inferior is halted.)
I was able to run this, from a debugging session in which the inferior was halted somewhere, with either the print or call command followed by the name of the function, with the name of the vector in brackets. There must be no semicolon. I found the print command better, since GDB would report the return value, which was "void". My function used C++ constructs such as "<<" to write to the text file.
A call within my dump function of the C function system("pwd") resulted in the current directory being output on the inferior's terminal window. Likewise: print system("pwd"). print system("mc") dutifully ran Midnight Commander in the inferior's terminal window.
I altered the function to return a string, which GDB reported in the GDB "Debugger > Output" console. I added a line: std::cout << "xyz"; - but nothing appeared on either the inferior's terminal window or in the GDB console.
My attempts to use the compile command to call my dump function in exactly the same way produced no results, with or without a trailing semicolon.
I found thatprint and call work with C and C++ code while `compile" only works with C code.
I tried print vvv[6].mmm for data members which were integers, floats, and strings and GDB returned their values correctly. Adding a ++ at the end caused it to return the original integer value, but the value itself was incremented.
When I tried print with a compound line of code, with a semicolon between the two logical lines, with and without one at the end, there was no response.
The GDB Developers list is not the place for support requests, but I did not know a better way to find out about the status of this facility.
How would I manage to highlight errors and warnings generated by ninja when I compile cpp? When I get errors, I only see white text, and it would improve readability if I could highlight errors and warnings.
You do not see errors because the compiler notice it is not outputint its message to a terminal, so it defaults to no color. With GCC you can force colored output with the -fdiagnostics-color=always command line option.
In case there is still someone out there struggling with this (like how I was not too long ago), here's what worked for me:
As this link and Oliv highlighted out, one needs to force Ninja to use colors (via -fdiagnostics-color on GCC>=4.9 or -fcolor-diagnostics for Clang)
This will force Ninja to format the specific output elements with the format defined in the GCC_COLORS environment variable.
FYI: If this variable is an empty string, then there is no coloring at all.
On how to configure this, see https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Language-Independent-Options.html, where the default configuration is also included as an example.
I am trying to compile a code with crayftn.
I get an error message
/opt/cray/pe/cce/10.0.1/binutils/x86_64/x86_64-pc-linux-gnu/bin/ld: failed to convert GOTPCREL relocation; relink with --no-relax
So it wants the flag --no-relax? OK, I can do that. So I re-link with that flag, and then it tells me
ftn -O3 --no-relax -dynamic -h pic -h omp -o stream_cray stream_mpi.o mysecond.o
ftn-2115 crayftn: ERROR in command line
"-no-relax" is an invalid command-line option.
So it asks for "--no-relax", but then it doesn't understand it. Anyone know of a way out of this conundrum? Or another way of solving the root problem in the first place?
I found this link:
https://bb.cgd.ucar.edu/cesm/threads/failed-to-convert-gotpcrel-relocation-relink-with-no-relax.4494/
PROBLEM:
Hi, I get the following error message for CLM5.0 compilation with
Intel compilers, during the final cesm bld ..ld: failed to convert GOTPCREL relocation; relink with --no-relax
SOLUTION:
Hi, Seems like found a solution to fix the compilation ...Adding of
"-Wl,--no-relax" in LDFLAGS does not solve this problem, but
"-mcmodel medium" in FFLAGS fixes this issue, after searching for
"Relocation truncated to fit" in google search engine, it comes up
with this link which was helpful to solve the issue
"https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268394"
Best Regards,Prabhakar
See also:
https://community.intel.com/t5/Intel-Fortran-Compiler/relocation-truncated-to-fit/td-p/1146616
This looks like mixing compilers and libraries from different systems
mixed up, either 32bit vs. 64bit or installations for ifort and
mpiifort based on different glibc or something similar.
I'm still curious about your "development environment":
Q: Have you been able to successfully compile, link and run ANY
program with your crayftn? Q: What version of crayftn? 10.0.1? Q: What
platform? Where is x86_64-pc-linux coming from? Just curious...
Wondering if it is possible to generate interleaved source and assembly from clang?
I am looking for something equivalent to gcc command (as demonstrated at http://www.fclose.com/240/generate-a-mixed-source-and-assembly-listing-using-gcc/)
gcc -Wa,-adhln -g source_code.c > assembly_list.s
I have visited Link: How do you get assembler output from C/C++ source in gcc? but it gets so far as to list the assembly - but no interleaving.
Also Visual Studio does give you pretty nice interleaved assembly output, details here: How to view the assembly behind the code using Visual C++?
Thank you for all the help.
Sarang
There seems to be a bug reported sometimes last year stating exactly this: http://llvm.org/bugs/show_bug.cgi?id=16647
Bug 16647 - No option to produce mixed source + assembly listing?
So since it is still NEW I guess clang does not have this supported yet.
As an alternative, how about compiling your code and then use objdump -S ? The output format is somewhat similar ...
As of August 2016, the bug that #dragosht mentioned still is open. However, there is a workaround offered by the linked bug 17465: clang -no-integrated-as -Xassembler -adhln. It disables the clang-integrated assembler and calls an external assembler, which hopefully supports the listing-generating options.
That works OK in Linux, but it doesn't work in Mac OS X (as of 10.11.6). The problem is that even the external assembler in OS X does not support the listing-generating options - you can check that with man as.
objdump -S is an alternative that also works well in Linux, but Mac OS X's alternative to objdump is otool, which does provide disassembly but not source interlacing. Hopefully that will change soon-ish, because otool seems to be on its way out while llvm grows its own objdump. See man llvm-otool.
Finally, for OS X the best option seems to be using gobjdump -S, from binutils. It can be installed with MacPorts or brew.
You can Generate Assembly Code from a .cc/.cpp source file by using this command
clang++ -c -S test-function.cc
I'm debugging a nasty problem where #includeing a file(not anything I wrote, for the record) causes a crash in my program. This means, I have working and broken, with only one C(++) include statement changed. Some of the libraries I'm using don't have debugging information.
What I would like to do is get GDB to output every line of C++ executed for the program run, and x86 instructions where not available to a textfile in such a format that I can diff the two outputs and hopefully figure out what went wrong.
Is this easily possible in GDB?
You can check the difference between the pre-processed output in each version. For example:
gcc -dD -E a.cc -o a.pre
gcc -dD -E b.cc -o b.pre
diff -u a.pre b.pre
You can experiment with different "-d" settings to make that more verbose/concise. Maybe something in the difference of listings will be obvious. It's usually something like a struct which changes size depending on include files.
Failing that, if you really want to mess with per-instruction or line traces, you could probably use valgrind and see where the paths diverge, but I think you may be in for a world of pain. In fact you'll probably find valgrind finds your bug and then 100 you didn't know about :) I expect the problem is just a struct or other data size difference, and you won't need to bother.
You could get gdb to automate line tracing. It would be quite painful. Basically you'd need to script it to run "n" (next line) repeatedly until a crash, then check the logs. If you can script "b main", then "run", then infinite "n" that would do it. There's probably a built-in command to do it but I'm not aware of it.
I don't think GDB can do this; maybe a profile will help, though? Are you compiling with gcc? Look at the -p and -pf commands, I think those might be useful.
The disassemble command at the gdb prompt will disassemble the current function you are stopped in, but I don't think outputting the entire execution path is feasible.
What library are you including? If it is open source, you can recompile it with debugging symbols enabled. Also, if you're using Linux, most distributions have -dbg versions of packages for common libraries.