List of functions called till a breakpoint gdb - gdb

I am using gdb to trace a program's execution flow. I am using an open source codebase and using certain library functions for my task. I am interested to know the path the program takes to reach the particular function, where I have placed a breakpoint. Is there a way in gdb to list all the functions called before the breakpoint is reached. I am looking to add a field to a particular data structure and it can be done only if I know in which exact function is the data structure being modified.

I am interested to know the path the program takes to reach the particular function, where I have placed a breakpoint.
This is possible by setting a breakpoint on every function, with something like rbreak ., but is not a viable approach for anything larger than tiny toy programs.
Is there a way in gdb to list all the functions called before the breakpoint is reached.
No.
I am looking to add a field to a particular data structure and it can be done only if I know in which exact function is the data structure being modified.
You are holding it wrong. You are trying to replace code understanding and indexing tool with GDB, but GDB is not such a tool.
Further, knowing all functions that have been called before the breakpoint in no way answers "which exact function(s) modified the structure" -- you get a superset instead. That superset can be 1000 times larger than the set you are interested in.
TL;DR: read the source, use tools that help with code understanding and indexing, and don't try to use GDB as such a tool (you'll fail).

Related

Can I debug (step through) code without a main() function?

Assume I want to understand a larger project by just stepping through the code with a debugger. Is it possible to just jump in at an arbitrary point (given I define the correct variables)? How do I debug libraries that don't have a main?
To debug code in a library, write a little application (that has a main()) that calls the functions in the library you need to debug. Then debug that application and step into the library calls it makes.
As for just "jumping into an arbitrary location" - well, you can instruct the debugger to move the instruction pointer to wherever you please, but that's usually not what you want, because you'd be missing a lot of state that previous parts of the program will have created. Usually what you want to do is set a breakpoint in the function you are interested in and then just run the program normally until you hit the breakpoint.
The best way would be to run the application as it is and set a breakpoint whenever you want to look. The thing is that the program might do lot of initialization and other stuff, that you wouldn't be able to figure out.
Another approach would be to look out for unit tests. They are like small programs itself targeting just specific parts of the program.

find position of a list term in gdb

I'm wondering if it is possible, within a debugging session, to tell gdb to go over all the terms of an std::vector and print out the indexes of those that satisfy a certain condition. In my case I have vector, and I would like to know which of the terms are negative.
I am well aware that this can be accomplished using conditional breakpoints, but for that I would have to rerun the program and place the breakpoint in the position where the vector is initialized, but it's less convenient.
There is no way of doing what you are asking for with plain gdb. The debugger does not have a language in which you can run arbitrary queries. That being said, the debugger does have support (at least not ancient versions) to load python scripts that will interact with data.
You can define scripts in the gdb command line, or else you can define them in files and load them from the command line.

Printing current call stack in OCaml

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...

C++ Peeking at the stack for caller info

Is it possible to 'peek' at the stack enough to deduce, perhaps by mapping an address to the debug .map file or something, what the calling function is programmatically?
I have a function that is called from a ton of different places, and basically if possible I would like to be able to programmatically log out who called the function so that I can trace the progression of parameter values over time, and be able to connect them back to where they may be going wrong. I could add a parameter so that the caller must provide a user string or something, but I'd like to do something less intrusive if it's possible.
GCC has features for this, such as __builtin_return_address (see http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html). They should be used only for debugging or special testing purposes and not as part of production code.
You can generate MiniDump files using windows API and load them later in the debugger and if symbols are available you should be able to debug the crash and investigate values of variables.

C/C++ Question about trace-programming techniques

I have the following question and from a systems perspective want to know how to achieve this easily and efficiently.
Given a task 'abc' that has been built with debug information and a global variable "TRACE" that is normally set to 0, I would like to print out to file 'log' the address of each function that is called between the time that TRACE is set to 1 and back again to 0.
I was considering doing this through a front-loading / boot-strapping task that I'd develop which looks at the instructions for a common pattern of jump/frame pointer push, writing down the address and then mapping addresses to function names from the symbolic debug information in abc. There could be better system level ways to do this without a front-loader though, and I'm not sure what is most feasible.
Any implemented techniques out there?
One possibility is to preprocess the source before compiling it. This preprocessing would add code at the beginning of each function that would check the TRACE global and, if set, write to the log. As Mystagogue said, the compiler has preprocessor macros that expand to the name of the function.
You might also look at some profiling tools. Some of them have functionality close to what you're asking for. For example, some will sample the entire callstack periodically, which can tell you a lot about the code flow without actually logging every call.
Looking for a common prologue/epilogue won't work in the presence of frame-pointer omission and tail call optimization. Also, modern optimizers like to split functions into several chunks and merge common tail chunks of different functions.
There is no standard solution.
For Microsoft compiler, check out _penter and _pexit hooks. For GCC, look at -finstrument-functions option and friends.
Also, on x86 Windows you can use a monitor such as WinApiOverride32. It's primarily intended for monitoring DLL and system API calls, but you can generate a description file from your application's map file and monitor internal functions as well.
(Edited: added link to GCC option.)
Make sure you've looked into the __func__ or __FUNCTION__ predefined identifiers. They provide a string literal of the function/method name you are currently executing.