In visual studio a object file (.obj) is generating after compiling a c++ file.
How to read and understand it?
Also how to see the code after compiler optimization in Visual studio 2015.
Please redirect if this is already answered.
Use the DUMPBIN tool from Visual Studio command prompt. Specifically, the /DISASM option shows you the disassembly. Do note the if you have link-time optimization enabled, then at least theoretically the final code may change after the .obj files are linked to form the final binary (.exe or .dll). You can disassemble those with DUMPBIN as well.
Dumpbin at the /all setting shows code sections & directories. Detailed explanations of things like code section characteristics is not common knowledge, but may be found in certain books. Here's a precis on COFF, here's a more detailed description, or there's even a WYSINWYX thesis.
Adding to #cynic's answer, in Visual Studio (15 & 17) it's possible to run DumpBin via the menu.
Go to Tools/External Tools and click Add.
Put in the Title box something like DumpBin Your_Exe or Your_Obj name and find the path for DumpBin if it isn't in the environment settings.
It can be similar to the following:
c:\program files (x86)\microsoft visual studio\2017\community\VC\Tools\MSVC\SDK-Version\bin\Host $(Platform)\$(Platform)\dumpbin.exe
and add it to the Command box. For arguments try something like:
/ALL /OUT:C:\Users\New\Desktop\dumpofYour_ExeName.txt "Pathname to your obj/executable file"
and yes, the quotes will work.
If using the desktop, put that in the initial directory box as well.
Select "prompt for arguments" if you wish to leave the Argument box blank.
You're sort of asking the wrong question: you say you want to see compiler optimizations but then you draw conclusions leading you to think you .obj files are required for that. That works, as cynic's answer shows, but there are alternatives which can be handier/better depending on the situation:
run code under the debugger, break, right-click any source file, select 'Go To Disassembly' and you can view source and assembly inline
have the compiler output assembly code (again optionally including source and machine code): go to project settings->Compiler->Output Files and set 'Assembler Output'
Related
Per default, when compiling a Visual Studio project in release mode, the complete path to the pdb is put into the image file, e.g.:
c:\myprojects\demo\release\test.pdb
Using an undocumented linker switch (/pdbpath:none) one can force Visual Studio 2008 to reduce the full qualified name of the pdb, e.g:
test.pdb
I need to do the same with a project which is still built using VC6.
I tried the "/pdbpath:none" switch at the project settings level, but the linker complains about this unknown switch.
Does anyone knows a method (or a tool) to accomplish this either when linking a VC6 project or afterwards directly at the image level?
Your best bet is to use pdbstr.exe from MS directly. It allows for direct extraction, update, and misc other functions directly, independent of compiler version (up to the last supported version, which I think is VS2013 right now). We use it to add SVN linkings directly to PDBs which we then store in local symbol stores using srctool.
For newer link.exe versions, the syntax changed.
The option you want is now /pdbaltpath:%_PDB%
It is documented on MSDN: https://msdn.microsoft.com/en-us/library/dd998269.aspx
%_PDB% expands to the file name of the actual .pdb file without any path information
For VC6, you might want to continue using the same compilers but a new version of link.exe.
The Windows Driver Kits also come with a tool named binplace.exe which can modify this information post-build.
I am a professional working for a software firm.In my past company basically i was working on C & C++ on unix.Now i suddenly shifted to C++ on Windows and i feel like i am in a completely different world.Basically i am working on a very big application which was totally written in C++.To keep it simple ,i dont have the source code .I have the exe of the application and several other dependent files.it is a GUI application(several windows,reports,graphs and huge mathematical calculations are done by this application).Now i finally have the source code of the application which includes some headers,some vcproj files,some dsw files and several other which i dont even understand why the hell are they present.
Now as i C++ programmer my responsibility is to make all the BUGS that the clients identify replicate and fix them.
If its a bug on unix i can simply use the binary and source code and run gdb/dbx and find out the issue in some or other way like adding adding some printf statements.
But given the files i mentioned above.how could istart debugging an application in VC++ in VISUAL STUDIO.
Is it very difficult for a C++ programmer to shift from Unix to Windows.
Is ther any good resource which i could refer for this kind of change where i could grasp things quickly?
given the exe and the source code of the application how can i start debugging a program by running the application in VS C++-(BTW i am using VS 2005)
The main difference is that on Unix, you'll have Makefiles, which you won't find on Windows. Visual Studio organizes your code in projects and solutions, and those project files contain all the information VS needs to compile&link your projects.
If you have a *.sln file, just double click it to open it in VS. Then build the source (usually by pressing F6) and run in debug mode (usually F5).
More details:
A project is a collection of source files that result in 'something', usually a LIB, a DLL or an EXE.
A solution is a collection of projects. Useful when e.g. one project creates a LIB that is used by another project. When you set dependencies between projects, VS will build the projects in the right order.
Extensions used:
*.vcproj : Project file for C/C++ sources
*.vcproj..user : contains which windows are open in the GUI.
Can safely be deleted.
*.sln : Solution file
*.ncb : Intellisense database for a solution. Can safely be deleted.
*.suo : contains which windows are open in the GUI. Can safely be deleted.
*.dsw : Visual Studio 6.0 related file - not used in VS2005. (Replaced by *.sln IIRC)
./Debug/* : folder with all
intermediate files for a Debug build
(can be changed)
./Release/* : folder with all
intermediate files for a Release
build (can be changed)
That's all I can think of at the moment.
If you only have a .DSW file and not a .SLN file, then it means that the project was probably last worked on with VC6 and not one of the later Visual Studio versions.
That's a shame, because there have been lots of changes to the C++ compiler since VC6, and you're probably going to find the project doesn't compile with VS2005 without needing some minor changes to source code.
Do you have a .SLN file - if so, what's the version number at the top of the file (it's a text file)? If you don't have a .SLN file, can you get hold of VC6?
I would always try to get stuff going on an unfamiliar platform with the best matching tools, before I tried to bring it forward to later versions.
I understand your pain; I took the same path a few months ago.
You probably figured it out, but Visual Studio is not the exact alternative of gcc/g++. It embeds a text editor, a debugger, and so on.
Usually, you have two compilation "modes", debug and release. (you can add your own)
When in debug mode, all optimization are disabled and you can execute your program in the debugger, use step by step, add breakpoints, ...
Just start it using the F5 key.
More notes on the additional files:
In the Visual Studio world, .vcproj files represents "projects": a bunch of file that belongs to the same project (source files, headers, resources, ...).
A .dsw (old name for current .sln files I believe) is a "solution" file: a group of one or several projects which can have internal dependencies. Example: you can have in the same solution, a library and a software that depends on it. So that when you compile the whole solution, things are built in the correct order.
First thing you should try is to attach to the process while it's running (Ctr-Alt-P and select the process) if you have the .pdb (debug information) files you should be able to debug the process without re-building it.
If that fails try to un-check the "Require source files to exactly match the original version" option in Tools -> Options -> Debugging.
If that too fails you'll have to build the application again (by opening the .sln file and performing a build) so that the binary matches your source files.
Good luck.
Compile the code with debug info and press f5 (Start Debugging). I don't see where is the problem. On linux is sort of the same.
VS2005 can convert the dsw file for you to a sln file, but you need all of the original VC6 files in order for the conversion to be successful. For debugging please check out following msdn link, I hope this will help you.
http://msdn.microsoft.com/en-us/library/sc65sadd.aspx
Please select hyperlink "Debugging Native Code" for C++ specific.
Problem: I have a large Visual C++ project that I'm trying to migrate to Visual Studio 2010. It's a huge mix of stuff from various sources and of various ages. I'm getting problems because something is including both winsock.h and winsock2.h.
Question: What tools and techniques are there for displaying the #include hierarchy for a Visual Studio C++ source file?
I know about cl /P for getting the preprocessor output, but that doesn't clearly show which file includes which other files (and in this case the /P output is 376,932 lines long 8-)
In a perfect world I'd like a hierarchical display of which files include which other files, along with line numbers so I can jump into the sources:
source.cpp(1)
windows.h(100)
winsock.h
some_other_thing.h(1234)
winsock2.h
There is a setting:
Project Settings -> Configuration Properties -> C/C++ -> Advanced -> Show Includes
that will generate the tree. It maps to the compiler switch /showIncludes
The compiler also supports a /showIncludes switch -- it doesn't give you line numbers, but can give a pretty comprehensive view of which includes come from where.
It's under Project Settings -> Configuration Properties -> C/C++ -> Advanced -> Show Includes.
We have found IncludeManager to be a very powerful tool. It is not free (but not expensive) out of development and free now. It only supports Visual Studio 2005 through 2013.
It allowed us to get a grip of our Include issues and drop our compile time from 50 minutes to 8 minutes by pruning out large chunks of includes we weren't using.
Not as good as gcc's hierarchical include feature, which shows the direct-line inclusion hierarchy in the case of an error. The "show includes" option in VS shows everything, which is overkill when debugging hierarchical include file problems.
There is now a plugin for Visual Studio called IncludeToolbox. It can list your dependent includes and do more things like a random remove and compile to see if that include was required.
Try redhat Source-Navigator for a more graphical solution.
I use Doxygen and GraphViz for class hierarchy graphics and a dependency tree in text for those.
Doxygen: Class Hierarchy
Doxygen diagrams: include hierarchy (classes)
Install both. Make sure to select GraphViz as the tool to generate the hierarchy diagrams. Select "Use dot tool from the GraphVix package".
Also make sure to include the binary directory from GraphViz into your PATH environment variable.
IncludeFinder is a good 3rd-party, FOSS tool. You can export results to XML, which will include data on number of occurrences and line numbers.
cl /P should show you the line numbers, such that you can tell the context of where a header file is being included from.
If you grep out the lines with ...
grep "^#line" file.i
... then you should have a pretty clean indication of what files were encountered in order by the preprocessor.
If it's a one off incident this should be a pretty quick diagnostic.
Update: I posted a comment on John Robbins blog about the. He wrote a response here:
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/06/19/do-pdb-files-affect-performance.aspx
The project I am working on does not build symbols for its release binaries, and I would like to change this.
Some info:
Mostly C++ code base, some C#.
Compiled under VS2k5, will be moving to VS2k8 Team System.
Time critical software.
Must have optimizations enabled.
Source code is provided to customer so full symbols are fine.
What are the best command line switches to generate what I need, and what, if any, performance hits am I going to take?
Also, are there any "Gotchas" to be aware of?
Generating debug symbols (ie PDB files) is just creating an external file that a debugger can reference when looking at your code in memory. It doesn't affect the code that the compiler or linker generate (sort of like generating a .MAP file).
Now if you're talking about defining _DEBUG in a release build, that's a whole different question.
Update: I posted a comment on John Robbins blog about the. He wrote a response here:
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/06/19/do-pdb-files-affect-performance.aspx
I found the following link on microsofts website:
Generating and Deploying Debug Symbols with Microsoft Visual C++ 6.0
This link pertains to Visual C++ 6, but I am assuming these instructions are the same for Visual C++ 8(2005) and 9(2008).
The information it gives is very similar to the link provided by TheBlack but more in-depth.
The /Zi switch in Visual C++ will create a PDB, but this setting also implies additional settings that will make the DLL or EXE larger. Specifically, /Zi implies /DEBUG, which implies /INCREMENTAL, /OPT:NOREF and /OPT:NOICF. The last three make the compiled DLL or EXE bigger, but they can be overridden by specifying /OPT:REF and /OPT:ICF in addition to /Zi. There is no need to override /INCREMENTAL, as /OPT:REF and/or /OPT:ICF will ensure a full, non-incremental link.
Source: Correctly Creating Native C++ Release Build PDBs
I don't know the command line, but you need to set debug symbols both in c++ compiler config (program database) and the linker (generate debug info) in the IDE.
If you find the settings in the project, you can use help to see which command-lines they refer to.
Is there any way to build/run small C++ programs, in Visual Studio without creating projects?
For example, if I have a file hello.cpp, can I compile it to hello.exe without a project?
GMan's idea of having a 'sandbox' project is a good one, as it allows for easily trying out multi-file tests. I call mine "cppTest".
However, if you just want to be able to compile whatever C or C++ file you happen to have open, just create a simple "External Tool". Actually, it's not as simple as it probably should be.
First, create a batch file that will set up the compiler environment and run the compiler. Something like the following:
#rem - runcl.cmd
#rem a batch file to drive simple VC9 compiles
#rem
#echo off
set LIBRARIES=kernel32.lib user32.lib advapi32.lib shlwapi.lib oleaut32.lib
set WIN32_WINNT=0x0500
call "%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"
echo Visual C/C++ 2008 (VC 9.0) Compile...
set CC="%ProgramFiles%\Microsoft Visual Studio 9.0\VC\bin\cl.exe" /Zi /EHsc -D_WIN32_WINNT=%WIN32_WINNT% %1 /link /incremental:no %LIBRARIES%
echo %CC%
%CC%
In the "Tools/External Tools..." dialog, add a new item and fill in the following fields:
Title: &Compile File
Command: c:\path\to\runcl.cmd
Arguments: $(ItemPath)
Initial Directory: $(ItemDir)
check the "Use Output Window" box
Now you can use the "Compile File" item in the Tools menu to compile whatever is the currently open file. You can even double click on the errors in the output window to take you to the lines with errors.
There are some limitations with this some of which you can fix by fancying up the batch file or maybe with a Visual Studio macro (I'm not very familiar with VS macros).
if you haven't saved the file, the compile will run against the most recent save. There's no option in the External Tools configuration to force a save.
if you run the command and there's not a C or C++ file active, the batch file will fall over
there are probably quite a few other areas where the batch file will get confused
The nice thing about a batch file like this is that you can also use it to help integrate the compiler into various editors that let you call external tools, like UltraEdit, Zeus Editor, EditPad Pro, PSPad, Programmer's Notepad, etc. etc.
If you like, I've posted a batch file that I use to integrate several compilers into editors like the above. This batch file handles several compilers including various MSVC compilers from version 6 through version 9, Digital Mars, MinGW and Comeau compilers (the compiler to use is selected by an additional parameter). The batch file is pretty convoluted (unfortunately, that's the nature of Windows batch files that have any kind of complexity). But I find it makes running these things from various editors pretty simple. I can quickly hit a few keys that I've assigned to the compilers to compile a single file against 5 different compilers so I can test for compatibility easily.
I make no promises about it other than I find it useful for my own purposes - if you do too, great. Otherwise, don't use it...
https://gist.github.com/mburr/3308168
Within the actual IDE, I don't think it's possible to run a small program, you have to use the command line like Matt suggested.
The solution I have for this problem, is that I have one project on my computers called "sandbox", which just has a main.cpp, and it's where I can mess around.
It let's me try things out here and there, but I never have to keep starting a new project.
One way to do this is to build a generic project such as sandbox, test, or even Hello World and then add and remove source files to change what you want to do. You can even remove the old source file and then add new to start over fresh. This is quick and easy while making it possible to return programs that are built.
If you have a hello.cpp file and would like it to compile into a hello.exe file without creating a project in code::blocks or visual studio you could look into: https://courses.cs.washington.edu/courses/cse373/99au/unix/g++.html
A guide on how to install g++ via MinGW on windows: http://www.codebind.com/cprogramming/install-mingw-windows-10-gcc/
Then you would be able to compile a single hello.cpp file by opening your command prompt, navigating to your file (the hello.cpp file) wherever you have placed it and run the command g++ -o hello hello.cpp which should result in a file with the name "hello.exe" in the same location as your hello.cpp.
Note that this is not part of visual studio but is an easy way to just compile a single .cpp file if you would like to keep it simple.