I compile my programs in a compiler machine. Later I run and test the programs in a different environment. If I compile with -fprofile-arcs on then the program tries to write a file in a folder which does not exist in the running environment. Is there a work-around for this problem?
Thanks
Further to RP's answer, I think this would be useful.
if the object file /user/build/foo.o
was built with -fprofile-arcs, the
final executable will try to create
the data file /user/build/foo.gcda
when running on the target system.
This will fail if the corresponding
directory does not exist and it is
unable to create it. This can be
overcome by, for example, setting the
environment as
GCOV_PREFIX=/target/run' and
GCOV_PREFIX_STRIP=1'. Such a setting
will name the data file
/target/run/build/foo.gcda.
Nakiya, According to this
"-fprofile-arcs
Add code so that program flow arcs are instrumented. During execution the program records how many times each branch and call is executed and how many times it is taken or returns. When the compiled program exits it saves this data to a file called auxname.gcda for each source file. The data may be used for profile-directed optimizations (-fbranch-probabilities), or for test coverage analysis (-ftest-coverage). Each object file's auxname is generated from the name of the output file, if explicitly specified and it is not the final executable, otherwise it is the basename of the source file. In both cases any suffix is removed (e.g. foo.gcda for input file dir/foo.c, or dir/foo.gcda for output file specified as -o dir/foo.o)."
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 want a run a build step that looks at a .h file, adds some code based on some external params, and hands the resulting file to the preprocessor.
I see the "Custom Build Step" in the project properties. It seems to need an output file. I just want to forward the results to the preprocessor.
It seems like the custom build step wants to do a 1-time process, not per-file or by file type.
The problem is that I don't know how to send my external executable the file currently being processed (eg, "HelloWorld.cpp"). $(InputName) and %(Filename) are blank and docs say it's deprecated. How do I send the filename to my external executable?
But even if I get that working, I don't want to set this per-file. I want all header files to go through this process.
Any ideas?
I've looked at:
https://msdn.microsoft.com/en-us/library/dd293663.aspx?f=255&MSPPError=-2147217396
https://msdn.microsoft.com/en-us/library/hefydhhy(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff770593(v=vs.140).aspx
working on a debug, x64 config on windows.
First of all, No, you cannot modify a file and pass along the results to the next stage (that I could see). I'd need some sort of Program Transformation System.
So I need an intermediate file. That file has to be added to the project, even if it gets overwritten by your code generator. I can associate c++ header files with a custom build tool, and they will all get called one-by-one in the stage of the build specified in the Custom Build Step. The custom build tool will modify the intermediate file(s), and all is well.
The VS 2015 name for the current file being processed is %(Filename). In older versions it has been $(ProjectName) and $(InputName).
According to the official guideline of lldb, the ability to view source code during debug session (using the command source list) is done by setting new pathname for source files.
i.e. if i compiled my project in /tmp on one computer and deployed it on another computer where the source code reside in /Users/Src/ , i should type settings set target.source-map /tmp /Users/Src from running lldb in the deployment machine.
However, what happens if i got the executable from someone else, and don't know the build directory. and maybe the source-code is organized differently from where is was built (but the file contents is the same).
my questions are :
Does lldb know how to search for matching source file recursively in the supplied path ?
How can I get the original pathname form the mach-o executable ?
here's the formal description of the command :
Remap source file pathnames for the debug session. If your source files are no longer located in the same location as when the program was built --- maybe the program was built on a different computer --- you need to tell the debugger how to find the sources at their local file path instead of the build system's file path.
If you know a function name in the code in question, do:
(lldb) image lookup -vn <FunctionName> <BinaryImageNameContainingFunction>
and look for the CompileUnit entry. The path given there is the path lldb got from the debug information.
I have an executable that was built with g++ -O0 -g (GCC 4.3.4) and immediately the source code was archived. At a later time it was altered. I now want to debug the original version. The executable saved the location of the original source code, which right now is populated by a different version with the same file names. I want to point GDB (GNU gdb (GDB) SUSE (7.5.1-0.7.29)) to the old source code. I have extracted it to a new location. I have tried setting the directory and substitute-path. Each time the loaded source code is the modified version. The commands I'm using are:
set directories /.../PILAGER2/unzip/source/
set substitute-path /.../PILAGER2/source/ /.../PILAGER2/unzip/source/
I have replaced the bulk of the path with /.../.
However if I type info source when the break point is reached the wrong file is shown. If I delete the files from the original location the correct ones are used. How do I properly tell GDB to use the source files from the unzipped location?
In my case the disk system was on a separate server. Using the path supplied by the administrators was actually a link to a location on a parallel fileshare. Using the actual path on the Panasas system worked. In my case that means the path started with /panfs/ followed by the server instead of /project/...
I'm trying to use Mac Instruments Time Profiler to optimize my code for building a MandelBox. I found how to make my executable my target process, but when the program runs, it gives me an error in the Console window saying it cannot find the .txt file associated with the program.
Do I need to tell the profiler where to look to find the file? The text file is already in the same directory as the executable. Any thoughts? Thanks.
This problem is not unique to Instruments. The same thing would presumably happen if your current working directory was something other than the location of your program. For example, if you were to do cd / ; /path/to/yourprogram.
You either need to make your program find its own location and then find its text file as a sibling in the containing directory or take the path of the text file as an argument. Or, you will always have to set the working directory to your program's location before invoking it.
That last approach is an immediate workaround for the problem with Instruments. On the panel where you choose the target executable, you can also configure various parameters, such as arguments, environment variables, and the working directory. Set the working directory to the directory that contains the text file and it should work.