I'm debugging assembly code. I use stepi, but it would go into callees. How to skip the call instructions as using "n" when source code is available?
Pretty simple: nexti is to stepi as next is to step
Related
I'm debugging a C++ program in gdb and stepping through the code. At various points the debugger will start stepping through the code in libraries/included files which is very tedious and not helpful for me. Is there anyway to suppress or 'jump' out of this information. I'm only concerned of following the trace as pertains to the current .cpp file.
At various points the debugger will start stepping through the code in libraries/included files which is very tedious and not helpful for me.
You are probably trying to step through code that looks something like this:
std::vector<int> v = ...
foo(v[i]); // Want to step into foo, but step will get into
// std::vector::operator[](size_t) instead.
The need to step over uninteresting "accessor" functions has been recognized long time ago (bug) but nobody implemented this in GDB yet.
Your best bet is to use the finish command when you find yourself in uninteresting function, and step again.
You can also ask GDB to ignore certain functions while stepping with the skip command. Documentation.
I'm working with some new code, in c/c++ while most of my experience has been in higher level languages.
I can read the code or run it in the debugger and step through it, but I wonder if are tools which will do any of the following:
-Record how often a line is executed so I can run the program for a while and see which parts are critical and which parts are rarely called (perhaps the code is instrumented and I get the program dump to extract out the info)
-Record the order in which lines were executed so I can run a program for a very short period, execute some relevant action in it, and see which paths the program took. Obviously code coverage is not enough, I will need to know the order in which lines were executed.
I have a rather long function containing a loop which I want to optimize. When I compile the code using gcc -S -O3 i get some thousand lines of assembly. How do I find the corresponding assembly code for the loop I am interested in ?
It will be best to use a debugger, such as ddd and look at the corresponding assembly code.
The easiest way is to set a breakpoint, run your code and you'll see the disassembly with all the symbols corresponding to your code.
Is there a way in OCaml to get the current call stack programatically? By this, I do not mean inside a debugger but as a function call inside the program that will print the current call stack. I imagine this should not be beyond the capabilities of the byte-code interpreter, especially if debug symbols are available.
I came to this question looking for the same thing, here's my solution
Printexc.get_callstack 5 |> Printexc.raw_backtrace_to_string
(Its actually a pretty good way to familiarize yourself with a new code base)
You can also use ocamldebug, with which you can start your code, compiled in bytecode. In this environment, Printexc.get_backtrace () are far more completes.
For native code one can use glibc's backtrace, though it may not print all stack frames correctly.
Unfortunately, the only way to get a backtrace from inside the code is when an exception is raised, you can then use Printexc.get_backtrace (). It won't give you though the names of the functions, just the locations in the code of what is in the stack, and only if OCaml was able to recover them...
I have the following:
classA::FuncA()
{
... code
FuncB();
... code
}
classA::FuncB(const char *pText)
{
SelectObject(m_hDC, GetStockObject ( SYSTEM_FONT));
wglUseFontBitmaps(m_hDC, 0, 255, 1000);
glListBase(1000);
glCallLists(static_cast<GLsizei>(strlen(pText)), GL_UNSIGNED_BYTE, pText);
}
I can hit breakpoints anywhere in FuncA. If I try to step into FuncB, it steps over. It will accept a breakpoint in FuncB, but never hits it. I know it is executing FuncB, because I can put a MessagBox() call in FuncB and get the message box.
I'm new to VS2005 after a few years away from extensive VC6 usage. The one situation like this I recall from my VC6 days, is if symbol information is not available. However, in this case both functions are in the same file, so the symbol information must be correct. Also in that case I think you couldn't even set the breakpoint.
I've tried all the silly voodoo like rebuilding the whole solution.
What stupid thing am I overlooking?
EDIT: Added code for FuncB in response to comment about it possibly being essentially inline-able. (It's just the exact sample code from MSDN for wglUseFontBitmaps [minus comments here]). I don't see how inlining that would impede stepping through each call.
Make sure all compiler optimizations are disabled (/Od). Compiler optimization can cause problems with debugger breakpoints.
Not sure what the problem is, but one thing you might try is to look at the disassembled code. You can switch betwen the source code and disassbled view with VS. I do not have the IDE in front of me at work, so the terms might be slightly off.
If you put the debugger into this mode, you can see what the assembly instructions that are executing. This helps sometimes to determine these kinds of problems. Sometimes, although not usually with a debug build, calls are optimized out by the compiler.
If everything fails try updating to VS2005 SP1 if you don't already have it...
Sounds strange indeed!
Thanks for posting the code. This is clearly not what I had guessed.
For posterity's sake, and to clear things up, my guess was that if (1) the function was one line and (2) the compiler inlined the function, then (3) the debugger might not know how to step into it. This guess relies on the fact that some debuggers do have trouble with inlined code and other compiler optimizations. I'm not familiar enough with Visual Studio's debugger to say whether it is on that list.
On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but will probably make other debuggers crash or refuse to read the program. ...
GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.
The GCC manual used to have a statement that some compilers would refuse to emit debugging symbols in optimized code because their debuggers couldn't follow it.
actually i had a similar problem, found out the code wasnt getting compiled when i was running the program, so make sure you 'compile' the program before you try running it