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.
Related
I am no expert in VSCode, but I saw that since version 1.38 there is the possibility to add watchpoints (a breakpoint which breaks when a given memory area is modified, a feature that is supported by many debuggers), at least for C/C++, see here https://jaxenter.com/vs-code-1-38-161797.html and here https://github.com/microsoft/vscode/issues/58304. Now my version of VSCode is 1.48.2, and I still can't figure out how to do it, and I couldn't find a proper explanation either. If anyone can give an explanation on how to do it (or whether it is possible), for sure it will very beneficial for me and for the VSCode community.
I personally use the CodeLLDB extension for C++ debugging as I use LLDB. The way I create a variable watchpoint:
Put a regular break-point at where the variable is defined
Upon hitting the break-point, find the variable in the Variables pane, right click, and choose Break When Value Changes
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).
I am trying to find a tool that can show me information about all the data structures in a program. I want to know when certain data structures were accessed and how their sizes changed throughout the course of the program. For example I want the tool to know that all the nodes in a linked list belong to one single data structure. Does a tool like this exist? I couldn't seem to find one through googling. Thanks
Some Toolchain, for example, Xcode's Toolchain, provides debugging features, which allows you to keep track of the memory use, CPU times and network using. The tracking data structure in memory could be achieved if you set breakpoint in the program. Without breakpoint, it's not likely to track the change of data structure since the CPU usually runs pretty fast. What you need is a good IDE with debugging, profiling ...
My first question is: what's your compiler? One person mentioned gdb as a useful tool, but that's only the case if you're using gcc/g++. Xcode has its own compiler/debugger. MicroSoft has its own as well.
Ultimately, this is about knowing how to use the debugger for your compiler. Also, realize that using the debugger for your compiler properly can be just as daunting a task as learning how to use your compiler.
There are also profilers available, but again, it will depend somewhat on your compiler as to which ones are available for you. Your keywords for googling will be "C++", "debugger", and "profiler", ideally along with the name of your compiler.
Be aware, as well, that your compiler may impact the statistics when your program runs against the same data.
So I'm not a big CS guy, so bear with me as I try to explain this adequately enough.
At work, I use a program written in Fortran 77 to do some modeling. Our debugging has been an issue, due to some IT constraints that are outside my control. When we attempt to use GDB, the compiler loads. When you run the program, it fails through internal logic checks. The program's looking for an input file, but it can't find it because GDB does not load another file that has a list of all the directories the input file, and other relevant files, could possibly be in.
The relevant code:
...
logical exst
...
INQUIRE(FILE='KEYWORDS',EXTST=exst)
if(exst)then
...
endif
End code
This DOES work when I run the program. The KEYWORDS file is found, read in through a call within the if statement branch, which allows the program to find the input file. When debugging, however, exst is always false, preventing proper read in, and failing later through logic checks.
Does GDB require certain permissions? The only thing I could find in my own search was a possible issue on signed/unsigned reported file size incompatibility, but outside of understanding what signed and unsigned values are, the explanation was a bit over my head.
Any help is appreciated. Will try to provide more information where requested.
gdb doesn't change the permissions of the program it runs. It runs under the same user id, as usual.
Normally when this sort of problem arises, it comes from an environmental difference. Typical sources are the current working directory, the command-line arguments, or environment variables. It's also reasonably common to have a wrapper script that invokes a program properly, but then when running in gdb, one does not use the wrapper and then improperly duplicates the setup that it provides. Less common but also still possible is code in .gdbinit messing with the environment inside gdb. So be sure to double-check things with pwd inside gdb, etc.
I am working on a huge program that employs a (custom built) micro-threading solution. It sometimes happens that I need debug a crash. During such times, it is useful to be able to switch from one micro-thread to another.
If I'm doing live debugging, I can replace all of the registers to those that came from the micro-thread context. I have written a macro to do just that, and it works really well.
The problem is that I cannot change the register values if I am doing post-mortem debugging (from a core file). In such a case, I have no way to tell GDB to change its concept of what the current frame is, as all registers are considered read-only in that case.
Is there a way to tell GDB about my custom context management?
Shachar
There's not a simple, built-in way to do this in gdb.
I think probably the simplest way would be to write a version of gdbserver that can read your core files and that presents your micro-threads to gdb as real threads. There's been at least one gdbserver out there that can read core files already, so maybe it isn't crazily hard. However, I couldn't really say for sure.