I was trying to verify if my macro really works during compilation by md5sum command in ubuntu.
For example, by "nvcc -DTEST_MACRO ...." I got an executable A.
Then by "nvcc ..." I got an executable B.
Of course the md5 values are different.
But, I recompiled and generated A again. Its md5 is different from previous one.
I took a pure c++ code and checked with g++, and its md5 value turns out to be the same no matter how many times I compiled. So I think there is something like time stamp in the executable generated by nvcc.
Just out of curiosity, how do I verify if my thought is right?
Anyway, how do I verify if "TEST_MACRO" really works in this case?
I think this variability is not necessarily due to an embedded timestamp, but rather by the way nvcc builds executables.
nvcc is a compiler-driver, meaning it launches a sequence of commands "under the hood" to compile code. During the execution of this sequence, a variety of temporary files are created with randomly-generated filenames. You can get a sense of this by looking at the output of your nvcc compile command with the -v switch added.
Some of these filenames do get embedded in the executable, and since these randomly-generated file names vary from one invocation of the nvcc compile command to the next, the resultant binary will vary.
If you want to verify this yourself, run your nvcc command with -v added. Then inspect the output at the end for a tmpxft... filename. Then grep the generated executable for that filename, eg.:
grep tmpxft_0000a76e myexe
(replace the tmpxft_0000a76e with whatever appears in your nvcc verbose output, and replace myexe with the actual name of your executable.)
If you want to verify if a TEST_MACRO really works, there are a few options. The least intrusive might be to put the following line in your TEST_MACRO body:
#ifdef TEST_MACRO
...
#warning TEST_MACRO_COMPILED
...
#endif
and you should see this echo'ed to the output during compilation, when you specify -DTEST_MACRO
(The above is a useful technique to avoid mistakenly including debug macros and other things you don't want in a production/release build of code.)
Of course, there are probably many other possibilities. If the test macro includes executable code, you could put a printf statement in it, to see evidence at run-time.
Related
Ok, n00b question. I have a cpp file. I can build and run it in the terminal. I can build and run it using clang++ in VSCode.
Then I add gtest to it. I can compile in the terminal with g++ -std=c++0x $FILENAME -lgtest -lgtest_main -pthread and then run, and the tests work.
I install the C++ TestMate extension in VSCode. Everything I see on the internet implies it should just work. But my test explorer is empty and I don't see any test indicators in the code window.
I've obviously missed something extremely basic. Please help!
Executables should be placed inside the out or build folder of your workspace. Or one can modify the testMate.cpp.test.executables config.
I'd say, never assume something will "just work".
You'll still have to read the manual and figure out what are the names of config properties. I won't provide exact examples, because even though I've only used this extension for a short time, its name, and therefore full properties path, has already changed, so any example might get obsolete quite fast.
The general idea is: this extension monitors some files/folders, when they change, it assumes those are executables created using either gtest or catch2. The extension tries to run them with standard (for those frameworks) flags to obtain a list of test suites and test cases. If it succeeds, it will parse the output and create a nice list in the side panel. Markers in the code are also dependent on the exactly same parsed output, so if you have one, you have the other as well.
From the above, you need 3 things to make this work:
Provide correct path (or a glob pattern) for finding all test executables (while ignoring all non-test executables) in the extension config. There are different ways to do this, depending on the complexity of your setup, they are all in the documentation though.
Do not modify the output of the test executable. For example, if you happen to print something to stdout/stderr before gtest implementation parses and processes its standard flags, extension will fail to parse the output of ./your_test_binary --gtest-list_tests.
If your test executable needs additional setup to run correctly (env vars, cwd), make sure, that you use the "advanced" configuration for the extension and you configure those properties accordingly.
To troubleshoot #2 and #3 you can turn on debug logging for the extension (again, in the VSCode's config json), this will cause an additional "Output" tab/category to be created, where you can see, which files were considered, which were run, what was the output, and what caused this exact file to be ignored.
This messed with me for a while, I did as Mate059 answered above and it didn't work.
Later on I found out that the reason it didn't work was because I was using a Linux terminal inside windows (enabled from the features section) and I previously had installed the G++ compiler using the linux terminal so the compiler was turning my code into a .out file, for some reason TestMate could not read .out files.
Once I compiled the C++ source file using the powershell terminal it created a .exe file which I then changed the path in the setting.json as Mate059 said and it showed up.
TL;DR
Mate059 gave a great answer, go into settings.json inside your .vscode folder and modify "testMate.cpp.test.executables": "filename.exe".
For me it also worked using the wildcard * instead of filename.exe but I do not suggest to do that as in that might mess up something with the .exe from the main cpp file and what not.
I have been coding for over 5 years and would now like to take a step away from IDE's and try a project without one. I have the things I need to get started (I think), a HelloWorld.cpp file, the Windows Command Prompt open and Clang installed.
Now that I have these things my question is this - What do I need to type into the Command Prompt to make Clang take my C++ code in the HelloWorld.cpp file and compile it into a separate file containing the assembly code, and then make Clang take my assembly code and assemble it into a separate file containing the object code, and then finally make Clang take my object code and link it into a separate file containing the machine code?
Ultimately meaning at the end I will have 4 files, one with C++ code, one with assembly code, one with object code and finally one with machine code. The point of all of this being the ability to read and understand each stage of the process before running the file containing the machine code.
Being someone who has left the world of IDE's for the first time, I find the official Clang documentation very confusing and cannot find a straight answer to my question.
Same as with GCC, and I'll do you one better by first preprocessing the source file. In principle Clang also can emit LLVM bitcode or LLVM IR as two extra intermediate stages.
clang++ source.cpp -E
clang++ source.ii -S
clang++ source.s -c
clang++ source.o
This last one gives a.out as an executable file. You can define the output file for each command by appending
-o output.file
The extensions may not be 100% correct. Just check what comes out.
I have seen one other answer link but what I don't understand is what is basis.cm and what's it's use?
You are asking two questions.
What is basis.cm and what's it's use?
This is the Basis library. It allows the use of built-in functions.
How to compile and execute a stand-alone SML-NJ executable
Assuming you followed Jesper Reenberg's tutorial on how to execute a heap image, the next thing you need in order to have SML/NJ produce a stand-alone executable is to convert this heap image. One should hypothetically be able to do this using heap2exec, a tool that takes the heap image, e.g. the .x86-linux file generated on my system, and generates an .asm file that can be assembled and linked.
Unfortunately, this tool is not very well-maintained, so you have to
Go to the smlnj.org page and fix the download-link by removing 'www.' (this page and the SourceForge page don't contain the same explanations or assumptions about argument count, and neither page's download link work).
Download and extract this tool, and fix the 'build' script so it points to your ml-build tool
Fix the tool's argument use by changing [inf, outf] to [_, inf, outf]
Run ./build which generates 'heap2asm.x86-linux' on my system
For example, in order to generate an .asm file for the heap2asm program itself, run
sml #SMLload heap2asm.x86-linux heap2asm.x86-linux heap2asm.s
At this point, I have unfortunately been unable to produce an executable that works. E.g. if you run gcc -c heap2asm.s and ld heap2asm.o, you get a warning of a missing _start label. The resulting executable segfaults even if you rename the existing _sml_heap_image label to _start. That is, it seems that a piece of entry code that the runtime environment normally delivers is missing here.
At this point, discard SML/NJ and use MLton for producing stand-alone binaries.
This question already has answers here:
Detect GCC compile-time flags of a binary
(4 answers)
Closed 9 years ago.
Is there any macro in c++ (using gcc) to get the compilation options used to build the executable ?
I'm sure I saw something like that in some about dialogs.
any help will be appreciated
PS: while the question in Detect GCC compile-time flags of a binary interests in finding the options activated to compile a program, I'm interesting in finding the exact command line options used to compile my program from within this program source.
Apart from creating the compile string from the
Common Predefined Macros
, which seems hectic. I think there is an easy way to do it. The gcc -V on debian gives back flags used for configuration.
However, my shot would be to get full command in ./configure equivalent step and dump it to some file like config_line.h as a define.
Something like:
./configure:
#!/bin/sh
echo "#define conf_flags \"configured with: "$*"\"" >> config_line.h
#do some configuration steps here
#maybe even compilation itself
Then:
luk32:~/projects/tests$ ./test.sh --with=test
luk32:~/projects/tests$ cat ./config_line.h
#define conf_flags "configured with: --with=test"
You get full config line defined in the external file under a define statement. I think its fairly straight forward and easy to use. And no need for much compiler magic.
It is also worth of noting you can most probably (if not always) create such file(s) right before the actual compilation so they are actually up-to-date and valid during compilation step. Answer in get-the-compiler-options-from-a-compiled-executable would imply the executable already exists, which might be a bummer in some cases.
Note: I gave bash example, but I'm pretty sure you can output similar header file under any half-descent build system, be it make, qmake, cmake, etc. the bash begin the simplest case.
I think most of them have access to the command line they are invoked with, as well as they provide easy way to get actual compile command. For example to provide two literals, one with commands used for make like -j 13 and another g++ ... used for actual compilation step performed by make.
Note2: I know this is not an answer the OP asked, but I guess it serves his purpose in the 1st place.
Because I'm using qmake build system I came across this solution :
I added this line to the end of my pro file :
QMAKE_CXXFLAGS += -DFLAGS=\"$$QMAKE_CXXFLAGS $$QMAKE_CXXFLAGS_RELEASE\"
then retrieved what I want from the FLAGS macro
How do I analyze the core dump (using gdb)
which is not compiled with -g GCC option ?
Generate a map file. The map file will tell you the address that each function starts at (as an offset from the start of the exe so you will need to know the base address its loaded too). So you then look at the instruction pointer and look up where it falls in the map file. This gives you a good idea of the location in a given function.
Manually unwinding a stack is a bit of a black art, however, as you have no idea what optimisations the compiler has performed. When you know, roughly, where you are in the code you can generally work out what ought to be on the stack and scan through memory to find the return pointer. its quite involved however. You effectively spend a lot of time reading memory data and looking for numbers that look like memory addresses and then checking that to see if its logical. Its perfectly doable and I, and I'm sure many others, have done it lots of times :)
With ELF binaries it is possible to separate the debug symbols into a separate file. Quoting from objcopy man pages:
Link the executable as normal (using the -g flag). Assuming that is is called foo then...
Run objcopy --only-keep-debug foo foo.dbg to create a file containing the debugging info.
Run objcopy --strip-debug foo to create a stripped executable.
Run objcopy --add-gnu-debuglink=foo.dbg foo to add a link to the debugging info into the stripped executable.
that should not be a problem , you can compile the source again with -g option and pass gdb the core and the new compiled debug binary, it should work without any problem.
BTW You can generate a map file with the below command in gcc
gcc -Wl,-Map=system.map file.c
The above line should generate the map file system.map, Once the map file is generated you can map the address as mentioned above but i am not sure how are you going to map the share library, this is very difficult