I have already looked at other posts here on stack overflow on how to permanently change the disassembly flavor of GDB from att to intel syntax, however, I could not figure out how to do so.
I know that I have to modify a file called '~/.gdbinit' and put down the line 'set disassembly-flavor intel'. The problem is that I can't find a file called '~/.gdbinit' on my computer. I also don't know how to create such a file because I keep getting the error message 'The filename not valid' when I try to do so.
I hope someone can help me out. Thanks in advance!
On Unix style operating systems, the '~' is an alias for your home directory. The '.gdbinit' is just a normal file. Try this:
echo "set disassembly-flavor intel" > ~/.gdbinit
You will need to train yourself on an editor like vi or nano to edit the file further.
Related
I am running VSCode in Ubuntu to debug a C++ program. Debugging a console app with GDB is working fine except I really want to capture the console log output to a file. I cannot see a way or option to do this. Is there any option to capture this console log output?
Since there does not seem to be a native feature to save the output of a VSCode terminal, maybe you can use in said terminal a command allowing you to save that session.
See for instance "Gdb print to file instead of stdout"
gdb core.3599 -ex bt -ex quit |& tee backtrace.log
As mentioned, the output is written to backtrace.log and also on the screen.
As the OP Andy Tomlin mentions in the comments, this is not compatible with a debugger session.
We solved the problem by just handling it inside the app and redirecting cout internally to a file.
I have met a freaky problem during my internship. My work is to code with VTK in C++ and I worked on OSX 10.8.3.
When I want to debug my program, I ran the gdb and use instruction "file" to load my program, then I used "list" to show the source code to make a breakpoint by line number. Here goes the problem: this freaky gdb showed the source code of a VTK header file which I even hadn't included in my source code!
My program's name is read
I have tried to use gdb read then break read:15 to set a breakpoint but the gdb displayed "no source file named read" that is ridiculous!
I have noticed that gdb works well in my ubuntu 12.04 and when I use file read in linux's gdb, it just displayed
Reading symbols from /Users/apple/Dev/VTKRead/bin/bin/read...done.
but in my OSX 10.8.3's freaky gdb it displayed
Reading symbols for shared libraries ......... done
Reading symbols from /Users/apple/Dev/VTKRead/bin/bin/read...done.
I think that is the reason and I tried to change compiler to solve problem by install gcc4.8 in macport but cmake seems only accept the apple's gcc.
but the gdb displayed "no source file named read" that is ridiculous!
That is not rigiculous at all: you very likely don't have a source file called read. What you do have is probably called read.cc, or read.cpp, so try break read.cc:15.
That is my mistake: I didn't set the build tag to "debug" in ccmake, so the compiler didn't write the information into the file.
I don't have any idea how I could find the root cause of a C/C++ linux application's problem using the core files. I understand that core files are genereated when something unexpected happens to an application. But I don't know where to start. Can anybody give me a jump start?
Learn to analyze core-dumps from Here. This is where I learnt from. Yes it uses GDB.
And this
"gdb" is the main tool you can use to analyze Linux core dumps. Here are several good tutorials:
RMS's GDB tutorial
http://www.gentoo.org/proj/en/qa/backtraces.xml
Howto: Debug Crashed Linux Applications Like a Pro
Some generic help:
Install gdb using :
yum install gdb
gdb start GDB, with no debugging les
gdb program begin debugging program
gdb program core debug coredump core produced by program
gdb --help describe command line options
1- First of all find the directory where the corefile is generated.
2- Then use "ls -ltr" command in the directory to find the latest generated corefile.
3- To load the corefile use
gdb binary path of corefile
This will load the corefile.
4- Then you can get the information using "bt" command. For detailed backtrace use "bt full".
5- To print the variables use "print varibale-name" or " p varibale-name"
6- To get any help on gdb use "help" option or use "apropos search-topic"
7- Use "frame frame-number" to go to desired frame number.
8- Use "up n" and "down n" commands to select frame n frames up and select frame n frames down respectively.
9- To stop gdb use "quit" or "q".
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.
A while ago I changed my personal operating system to linux and my development enviroment to KDevelop.
However debugging c++ projects is still not working as it should.
My KDevelop version is 4.2.2 (I installed it through package management)
Every time I hit the "debug button" the application is starting with the console message
warning: GDB: Failed to set controlling terminal: Operation not permitted and debugging functionality is not available.
Any ideas welcome.
(If you need additional information don't hesitate to ask)
I also had this problem, but I use gdb in KDevelop sparsely enough that hadn't bothered me yet. Here's my log of trying to fix it:
Grepping through the GDB 7.3.1 source code reveals that this message is printed when GDB tries to set its master TTY to a newly-created pseudo-tty (see gdb/inflow.c, lines 683-740). In particular, a call to ioctl with request TIOCSCTTY fails with a permissions error.
With this in mind, I took a look at the Linux kernel source code to see what could cause a failure. A bit of searching shows that it will eventually degenerate into a call to tiocsctty(). The comment from tiocsctty that is important here:
/*
* The process must be a session leader and
* not have a controlling tty already.
*/
Since the only other reason it can fail with EPERM is if the tty that GDB creates is actually a controlling tty for another process (which seems highly unlikely), I thought it reasonable to assume that GDB is not a session leader. Fair enough, it's launched by KDevelop after all!
So: I tried not launching the GDB session in an external terminal, and it works. Problem narrowed down.
Originally, the external terminal line was set to konsole --noclose --workdir %workdir -e %exe. Changing this to terminator -e %exe made a slight difference: KDevelop warned me that
GDB cannot use the tty* or pty* devices.
Check the settings on /dev/tty* and /dev/pty*
As root you may need to "chmod ug+rw" tty* and pty* devices and/or add the user to the tty group using "usermod -G tty username".
I checked my permissions; my user was part of the tty group and all relevant files were readable and writable.
Grepping through the KDevelop source code reveals how KDevelop actually sets up the terminal. It runs the shell script
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
and then sets up GDB to use the terminal device it reads from FIFO_PATH. (My name, by the way, not the one that KDevelop uses.) The problem (as best I can tell) is that gdb is not launched as a child of the shell script, and thus cannot use it as its main tty.
I'm not feeling up to patching KDevelop to make this work properly as of yet (or finding what actually caused this to stop working in the first place . . .), so the best I can suggest at the moment is to simply not use an external terminal for debugging purposes.
Good luck! I'll update if I find anything useful.
As Arthur Zennig said, for more information, you need to do something
Firstly, you need to create the Terminal profile
Secondly, open Launch Configurations, fill info such as the image below
Good luck!
In case you got the error:
"Can't receive konsole tty/pty. Check that konsole is actually a
terminal and that it accepts these arguments"
RUN > CONFIGURE LAUCHERS > (See picture below. My project name was "loops")
What worked for me was to uncheck checkbox "Use External Terminal". Found the in the "Compiled Binaries" Tab.