I've been using trace points on C++ functions of interest to build a dynamic call graph in Graphviz. The syntax I'm using in the Breakpoint UI to do that is
"$CALLER" -> "$FUNCTION";
Unfortunately, the output isn't quite what i need, because while $FUNCTION expands to the full signature, $CALLER does not. Is there a way to get the signature of the caller in the same format as $FUNCTION? Without that, the node names on my call graph don't match. (I can get around that by removing the signatures for the callees after the fact, but that merges calls to overloaded functions, and isn't ideal.)
In VS 2010, there was a provision for invoking a macro when a breakpoint was hit. Is there a replacement for that in VS 2012 now that Macros are no longer supported?
Or is there a much simpler way to get this information? (I have the Performance Wizard, but I didn't think it had the same fidelity as the debugger, since it uses CPU sampling. And Intellitrace isn't supported for C++, so even if I had the Ultimate edition it wouldn't be an option.)
Thank you.
A good way to collect this information with Visual Studio is to use the Visual Studio Profiler in 'Instrumentation mode'. For more information, refer to MSDN.
You should be able to configure the profiler to collect the entire call-graph and C++ collection is supported.
Related
I am interested in finding out the differences (implementation wise) between timeGetTime() and GetTickCount() Windows API functions, as the source code will not be public, I am thinking to analyse their implementation using their assembly code in Visual Studio, Can anyone suggest any better idea ?
Use a debugger, like Ollydbg, x64dbg, IDA pro or Visual Studio itself for the user-mode code.
If you need to cross over to the kernel-mode side, use WinDBG.
Make a program, as simpler as possible, that invokes the APIs you want to analyze then:
Load it in the debugger, if it is not a system-wide debugger.
Put a breakpoint on the APIs.
Run the program.
Once it breaks, single step as needed.
The more the debugger understand of Windows (read more debugging symbols it has) the easier the analysis.
WinDBG has a rich symbols library but it is a bit hardware to use.
To understand APIs like GetTicksCount you may find useful this pages:
What is the KUSER_SHARED_DATA.
How to show the KUSER_SHARED_DATA memory region in WinDBG.
Who updates the KUSER_SHARED_DATA.
KUSER_SHARED_DATA
As Peter Corders supposed, Windows exposes frequently accesses information, like the tick counts, in a memory region shared across all user-mode processes.
GetTicksCount only copy data from that (with some synchronization in place).
Is there a MATLAB add-in to Visual Studio?
I found an old one that works with Visual Studio 6. There's also the Eclipse plugin, but I prefer Visual Studio as an IDE.
However familiar you are with VS, I would recommend abandoning it when you use Matlab. I've used multiple IDEs while developing code for Matlab, and I always come back to the built-in editor.
Matlab's editor is easy to use, and fully integrated with the program. Since Matlab is a scripting language, the debugger is also very flexible and interactive.
There are many useful features of the editor that would be (most likely) impossible in VS, including:
Group your code into "cells", which allow you to evaluate blocks of code on the fly
select some portion of your code, and evaluate it
an interactive variable editor, which is available both during debug mode, and outside of it
a command window that allows you to evaluate commands
a powerful command history, which allows you to view and evaluate past commands.
evaluate commands or other blocks of code while in debug mode. In fact, you can call any piece of code while debugging, and even debug that code as well!
tab completion for all variables, and functions currently on the Matlab path
The M-Lint feature helps improve code quality by providing feedback (in the form of underlines) on both errors and questionable usage
An example:
You are debugging a function, and you come to a tricky line of code to debug. Instead of stepping over that line, you can highlight it and evaluate it in the command window, or even some small portion of the line. In this way, you can fix your code iteratively without ever leaving the debugger.
The only time I would recommend using VS for Matlab, is when writing/debugging MEX functions. You won't use VS to compile them, but VS is definitely a better IDE for writing C/C++ code.
When developing software, always use the IDE that is best suited for what you are doing. Learning a new IDE can be daunting, but Matlab's editor has a relatively low learning curve compared to others.
I am using Visual Studio on Windows together with Intel(R) Visual Fortran Composer XE 2011. I have a big old code with thousands of subroutines. I did some substantial changes adding other hundreds of subroutines and now I am having some access violation errors, the which reason that I have hard time to identify. It is likely due to non-matching number of dummy/formal argument, since it happened to me before and the symptoms were the same and it took me 2 days to figure out where the problem was. Is there an add-on to Visual Studio to catch this kind of error? The programming style is fortran 77 and in no case I am required to provide explicit interfaces as for 90 standard. I know explicit interface would help but adding them for all the code would be days of work.
thanks
A.
I don't have VS on this machine so can't check exactly which Properties page you need to find, but there is an option, probably under Diagnostics, to have the compiler check procedure calls at compile time. On the command-line the compiler option is /warn:interfaces and it causes the compiler to check implicit interfaces. No plug-in is necessary, the Intel Fortran compiler incorporates the necessary functionality.
When I'm debugging something in Delphi and there's a system library in the stack trace, I've got the name of the library and the function that's being called into. Unfortunately, this doesn't seem to apply to any other external DLLs. I've got one that was compiled in Visual C++ 2005, and any time it gives me any sort of trouble, I have to attach the VS debugger and start tracing through the code from the original entrance point, because Delphi gives me no clue what's actually happening.
This DLL was built with VS's debug information compiled into it, but apparently Delphi has no way of reading it. Is there some way to fiddle with the debug options to change that, so I can get meaningful function names in my stack trace the same as I can with system libraries?
Delphi and Microsoft each use their own kind of debug information, and neither can use the other's kind.
These two pages might get you going into conversion:
Debugging symbols/tools using Delphi
Debugging Format Interoperability
But I'd just fire up Visual C++ 2005 and debug the C++ portion there. That is: the opposite of the solution in Stack Overflow question How to debug a DLL file in Delphi.
I've been doing some MSIL work and have come across references to these three debuggers.
What's the difference between them?
Is one of them better than the others wrt. functionality?
Are there others that I have missed?
I'm assuming you meant DbgClr not Clt and mdbg not mdbug?
DbgClr uses the VS shell so you get a nice GUI.
mdbg is the command line managed debugger.
cordbg was an old sample that sorta shipped, but now it's just a wrapper for mdbg. http://blogs.msdn.com/jmstall/archive/2005/11/07/views_on_cordbg_and_mdbg.aspx
Visual Studio is one you missed, but DbgClr should have the same functionality. http://blogs.msdn.com/andypennell/archive/2005/02/21/377621.aspx.
You can also use windbg with SOS extensions to do managed debugging from Windows debugger. SOS is also helpful when using VS since it lets you inspect memory and so on.
To see source level MSIL debugging, try using ilasm with the /debug option. Last time I checked, VS will let you step through the .il source just like C# or any other language.
MSDN blogs have a ton of content about debugging .NET apps -- I suggest you search further there.