When using GDB 7.4 or 7.5 (haven't tested older versions), is it possible to add breakpoints to files which reside in a folder path that includes commas? I've been trying to get it to work (when working on the debugger interface of Dev-C++), but GDB is interpeting my commands wrong.
I use the following command to send breakpoint commands to GDB:
// sets break at line 13 in mentioned file using filename:linenum
break "C:/Foo,Bar/main.c":13
In other words, \ is replaced by / to avoid accidental escaping and for extra safety "" is added around the filename. Should work fine right?
Well, no. For some reason GDB clips the file path and tries to execute:
break "C:/Foo":13
... and it throws a generic error:
"Error in re-setting breakpoint 1: Function "C:/Foo" not defined.
Any ideas how I can fix this? I haven't been able to find anything useful regarding commas and GDB filenames here and on Google.
You can't do that as gdb use comma to separate multiple expression, so it react as you give it two paths.
Related
I am running gdb 10.1.90.20210103-git and gcc/g++ 10.2.1 20210110 on x86-64 Debian 11. My IDE is Codelite, which uses the manual rather than the machine interface to gdb, and enables me to type commands directly to gdb, and see the response (potentially copying the response to the clipboard). This when the inferior is paused after hitting a breakpoiunt, via the gdb console, which is in Codelite's Debugger > Output pane.
I was able to use the instructions at: https://sourceware.org/gdb/current/onlinedocs/gdb#Compiling-and-Injecting-Code "Compiling and injecting code in GDB" to compile simple C code and make it run in the environment of the halted inferior. For instance: compile code blah++; increments a local variable int in the inferior, which I can see via the Locals or Watch panes.
The compile file command worked fine as long as I specified the absolute path of the source file.
I was unable to see console output (to the inferior's or gdb's console) for a simple printf() statement: `printf("xxx");' because the code would not compile if there was such a line
Despite using set debug compile and set debug compile-cplus-types and checking these are set with the show versions of these, I get no error messages or acknowledgements regarding whatever I try to compile.
The blah variable is an integer, which is accessible through C code and so gcc. The ability to increment this was the only indication that my code had compiled and run.
I could not get any responses to set/show compile gcc so I am presumably compiling with gcc. I did give the command set compile gcc /usr/bin/x86_64-linux-gnu-cpp-10, but there was still no response from show compile gcc or any change in the C-only behaviour.
I could not compile the file if it contained a C++ line which incremented a data member of a class object in an vector of such objects. Nor could I compile my code if it contained C++ code such as: #include <fstream> and/or std::fstream oFile;.
The gdb documentation mentioned above is general, but does have C examples.
Is it possible to compile C++ code under gdb, injecting it into the environment of the paused inferior, with any version of gdb and gcc?
I am keen to use this C++ code injection facility, if it exists, for dumping the contents of large, complex, data structures to files and and to modify some elements of same to aid debugging.
Summary: GDB's C++ compilation and injection system does not work for me, and it is reported to be buggy or non-functional. I only tested this compile command with single lines of C code, but it worked fine for these. I was able to run my function, which writes a text dump file containing the values of a vector of class objects' data members, while the inferior was paused after a breakpoint, by including it in a source file and calling it with GDB's print or call commands, giving it the required input argument of the name of the vector to dump.
I haven't tried using GDB on its own, but at present I have no reason to believe that Codelite is interfering with my ability to communicate with GDB via Codelite's "Debugger > Output" console.
I wrote to the GDB Developer list and received what I assume is a well informed reply. I was told that in my respondent's experience "the C++ plugin isn't very functional. It seems to have some bugs and crash pretty frequently as well. Also, it seems like nobody is actively working on it." This is consistent with my experience to date.
Perhaps later versions of GDB would work better. However, there has been minimal change to the library https://github.com/gcc-mirror/gcc/commits/master/libcc1/libcp1.cc since 2017, and I could find no indication of new work on C++ compilation and injection in https://www.sourceware.org/gdb/news/ since the announcement of its introduction:
GDB 8.3.1 was released on 2019-09-20, with: "Experimental support for compilation and injection of C++ source code into the inferior (requires GCC 7.1 or higher, built with libcp1.so)."
It is possible that my problem is related to not having this library. I do have the C equivalent: /usr/lib/x86_64-linux-gnu/libcc1.so.o. I could find no such library in a Debian package. It is possible I could get this going by compiling the latest GCC/G++ and GDB, but that is pretty daunting, involving installing later standard libraries than my current Debian installation has, while making those and the newer G++ and GDB available for Codelite sessions, but not interfering with other software on machine which needs the older compilation system.
The respondent suggested that instead of compiling and injecting fresh code in the middle of a debugging session, I could write it as a library, and run it by using the compile command, on a purely C piece of code which would call it. However, for my purposes, the function needs to be passed one or more C++ constructs, and any code which called a C++ function would be C++ code and so, presumably, not be compiled by GDB.
For my immediate purpose of doing text dumps of large vectors of class objects' data members, I was able to succeed by writing such a function in an existing source file, which also contains the functions I am debugging. Then I could call it with GDB's print or call commands. I imagine this would work if the debugging function was in any other linked source file, or in a linked library. (Perhaps there is a way of writing such a library, compiling and linking it while the inferior is halted.)
I was able to run this, from a debugging session in which the inferior was halted somewhere, with either the print or call command followed by the name of the function, with the name of the vector in brackets. There must be no semicolon. I found the print command better, since GDB would report the return value, which was "void". My function used C++ constructs such as "<<" to write to the text file.
A call within my dump function of the C function system("pwd") resulted in the current directory being output on the inferior's terminal window. Likewise: print system("pwd"). print system("mc") dutifully ran Midnight Commander in the inferior's terminal window.
I altered the function to return a string, which GDB reported in the GDB "Debugger > Output" console. I added a line: std::cout << "xyz"; - but nothing appeared on either the inferior's terminal window or in the GDB console.
My attempts to use the compile command to call my dump function in exactly the same way produced no results, with or without a trailing semicolon.
I found thatprint and call work with C and C++ code while `compile" only works with C code.
I tried print vvv[6].mmm for data members which were integers, floats, and strings and GDB returned their values correctly. Adding a ++ at the end caused it to return the original integer value, but the value itself was incremented.
When I tried print with a compound line of code, with a semicolon between the two logical lines, with and without one at the end, there was no response.
The GDB Developers list is not the place for support requests, but I did not know a better way to find out about the status of this facility.
I heavily used gdb before, and now give lldb a shot. I like gdb's start command very much, but I can't find the equivalent one from lldb's manual. Now I can only use "b main" followed by run compound instead. So just curious whether there is an equivalent one in lldb? Or I can only use the compound of "b main" and run commands as a work-around.
You are correct, lldb doesn't have a dedicated start command. The stated motivation for that command is that gdb supports lots of runtimes that don't use a "main" symbol. That makes determining where user code begins non-trivial, and it's useful to have a command that figures that out for you. We haven't had a need for that in lldb yet.
If you always use start to run programs in gdb, then you can just set a breakpoint on main in your ~/.lldbinit file. That will get copied to any new targets that get made in your lldb session, and run will behave exactly like start (for runtimes that use a main symbol).
If it's something you would use a lot but not always, you could make your own version fairly easily using the python extension point in the command interpreter:
https://lldb.llvm.org/use/python-reference.html#create-a-new-lldb-command-using-a-python-function
Also, feel free to file an Enhancement Request with http://bugs.llvm.org.
I am trying to debug a Go-program using gdb and setting breakpoints works normally in all packages, except for one. In my src-folder I have 3 subfolders that each contain packages:
crawler/
crawler.go
model/
page.go
urlutils/
urlutils.go
I cannot set a breakpoint in page.go on any line as it gives me the following error:
(gdb) break model/page.go:14
No source file named model/page.go.
Make breakpoint pending on future shared library load? (y or [n])
I do not understand why this is happening with only this one package. "model/page" is also an import in the file that contains the main function and is used when the program runs, so it must be in the executable. Does anyone have an idea?
I found a solution:
I needed to add a flag to my go build command:
go build -gcflags "-N -l" launch.go
This disables the code optimization performed by the go compiler which lead to my breakpoint working. The paths were correct and also the absolute path didn't work.
Nevertheless, thank you tomwilde for pointing me into a direction.
I am using gdb to debug NS-2 which is a simulator for network protocols. It takes an .tcl file as input and interpret it. [I think it is an interpreter.]
Some of the code is written in tcl (events and creation of network components) and some in C++ (especially Packet Formats, Agents etc.).
I have created an Agent in C++ and i want to stop it at some function call so that i can see the stack trace and find which other classes have been called before it.
This is what i have done:
There was some error in one of my MyAgent::function and it was giving Segmentation Fault and gdb was stopping there automatically. I could then see the stack trace. I rectified the error.
Now when i run
gdb ./ns
b MyAgent::function()
/*
When i press TAB after writing "b MyA" it gives me all functions
of my class :). when i press enter after above command --
it asks me "Breakpoint on future shared library load" and i say Yes.
I hope this is ok ??
*/
r myfiles/myWireless.tcl
Now it runs and do not stop anywhere. :(
I am sure that this function is being called, because when that Segmentation fault was occuring, it was stopping at that function.
Thanks
You can add a breakpoint in that function:
(gdb) break MyAgent::function()
You must make sure to compile with whatever options are necessary to get debug symbols. On GCC, use the -g or -ggdb options.
You need the -args option to specify the tcl script that will be executed.
Run gdb like this:
gdb -args ./ns path/to/tcl/script.tcl
To enable debug flag to c++ code, if have not done it already, re-configure your ns2 instalation with:
./configure --enable-debug ;# plus any other flags you use for configuring
make clean
make -j 3 ;# -j for faster compiling
make install ;# optional
You can also use the --with-tcldebug=..., for debugging tcl code (You need to install tcldebug first for this option)
I'm trying to get gdb to run programs with input redirection to stdin. For example, without gdb I would run a program like this:
prog < input.txt
Now in gdb, the usual way to do this is run < input.txt. However, it doesn't work for me and when doing this nothing gets redirected into stdin.
I'm using Windows with MinGW. What could be the problem?
As far back as the late '90s, broken command line redirection was a known and assumed limitation. My suspicion is that it remains that way, since the mingw32 port of gdb still gleefully passes on verbatim all run arguments (including redirects) to the debugee.
Several possible workarounds:
if you have the option to alter the command line interface, then implement bbadour's suggestion
otherwise, if you can easily suspend the process before the point you want to debug at, invoke the debugee (with redirection) from a shell and attach to it while it is already running
otherwise, if you have symbols for the debugee (gcc -g) or you know the address of main() (gcc -Wl,-Map,mapfile) and can set a breakpoint there, proceed in the following manner (tested with mingw gdb 6.8.0):
# gdb debugee.exe
(gdb) b main
(gdb) run non-redirect-arguments-if-any
(gdb) p dup2(open("/tmp/input.txt", 0), 0)
(gdb) c
I ran into the same issue here, and I just got into the habit of adding a command-line argument to allow grabbing input from a file.
e.g. Parsing a "-i ifile" argument using argc and argv to get input from ifile instead of stdin and parsing a "-o ofile" to write output to ofile instead of stdout.
Then I just use those arguments instead of redirects.
The tools that come with MinGW often are not the latest versions and often have features omitted. ::shrug::
Input redirection is supported starting with GDB 8.0. From the NEWS file:
Native debugging on MS-Windows supports command-line redirection
Command-line arguments used for starting programs on MS-Windows
can now include redirection symbols supported by native Windows
shells, such as '<', '>', '>>', '2>&1', etc. This affects GDB
commands such as "run", "start", and "set args", as well as the
corresponding MI features.