Hi I am using gdb version 7.5. Can someone tell me how I can get the vim keystrokes to work inside the gdb? The up and down arrow keys work for history but I want the k and j to work similar to when I am in a bash shell and have things set as set -o vi from the shell then my vim keystrokes work for command history. I used to have this set up using gdb in a previous linux instance. Currently running ubuntu 13.04.
gdb uses readline. So you just need to put the following command into ~/.inputrc to turn the editing mode to vi.
set editing-mode vi
Note: all programs that use readline will be affected by this setting this includes bash.
Over in this question about ndk-gdb I learned that C-M-j will cause gdb to enter vi mode. I tried that with gdb 7.4.1 and it worked, but I don't know about gdb 7.5. (Note: C-M-j means "Alt-Ctrl-j" for those not used to emacs nomenclature or "Esc Ctrl-j" if you don't have an Alt key.)
Related
Screen shot of window in debugging mode
Hey, I have a problem with debugger in vscode. I set it according to the vscode dowcumentation I set the debugger correct path but I don't why my debugger stuck at input cin and I tried to give input in base=2 , It unable to perform this action,Anyone please how to give input in debugg mode of cpp/c in vscode usin mingw64. Please resolved my issue.Tell how to provide input in debug mode
Enter base number: *running,thread-id="all"
2
Unable to perform this action because the process is running.
I think that's because it's running in output section !
go to vscde settings and find run in terminal and enable it
Firstly, in debugger console do NOT take input at cin or scanf. You shall use terminal for reading in inputs.
1st way: #JaMiT quoted C++ read input by using external console to true.
How do you configure to set the cpp file run in integrated terminal?
2nd way: Check your gcc/g++/gdb version and try to use an more updated version.
In my case, the version goes with mingw-w64 with git bash (GCC 6.2.0) is NOT supported by vscode Integrated Terminal for debugging. However, using an more up-to-date version - GCC (12.2.0) will show your debugging in your integrated Terminal (at least in my case).
Suggested alternative GCC installation: WinLibs - For Standalone GCC
python2.7.10,ipython5.0.0,linux
when I use my ipython console, the prompt and the inputting command is always twinkling, and I uninstall it and reinstall again, but the error occur again, I googled and did find any answer about it
If you are using SecureCRT, change the following settings, select Linux (I haven't tested other options), don't select ANSI, if you are using other terminals such as XShell, there are similar settings.
I would like something similar to bash command line, where we can rescue the last command, and navigate left and right among characters to edit the command before entering it.
Are there ways to edit the last command entered in gdb in AIX systems ? Or at least there are ways to come back some characters to correct it, rather than, delete all them with backspace ?
(I have noticed that dbg line-editing works fine in Linux)
You're using a copy of gdb built without libreadline support. Either go without it or re-build gdb from source w/ libreadline support.
GDB uses the same line-editing library as bash -- GNU readline. The editing you do in bash should work fine in GDB. It does for me.
Currently the gdb console of Eclipse just connects the stdin/stdout between the java gui and the underlying gdb process, hence many gdb shell features are missing, e.g. tab-autocomplete, command history etc.
I want to know if there is an enhanced console for fast gdb interacting. I really like the frequently used gdb commands like "print" and "call" etc. IMHO, "print" command is superiors sometimes than Eclipse "Expression watcher" because it only execute once and the later will be evaluated any time and be crash-prone.
If you think there is no need to use gdb console, then what's you best-practise in terms of gdb UI to eclipse UI transfer.
There doesn't seem to be any gdb-specific plugin, beside the initial gdb integration initiated with Eclipse3.4.
And the current list of gdb bugs doesn't include your missing features.
If you're writing c/++, why not just find the eclipse-generated elf and use gdb via the shell?
We're using the Eclipse CDT 5 C++ IDE on Windows to develop a C++ application on a remote AIX host.
Eclipse CDT has the ability to perform remote debugging using gdbserver. Unfortunately, gdbserver is not supported on AIX.
Is anyone familiar with a way to debug remotely using Eclipse CDT without gdbserver? Perhaps using an SSH shell connection to gdb?
finally I got gdb run remotly anyhow now. At the Bug-symbol on the taskbar I took Debug Configurations - GDB Hardware Debugging.
In Main C/C++ Applications I set the full path on the Samba share of the executable (X:\abin\vlmi9506). I also set a linked folder on X:\abin in the project. Then I modified my batch-script in GDB Setup. It's not directly calling gdb in the plink-session but a unix-shell-script, which opens gdb. By this I have the possibility to set some unix environment-variables for the program before doing debug. The call in my batch:
plink.exe prevoax1 -l suttera -pw XXXXX -i /proj/user/dev/suttera/vl/9506/test/vlmi9506ddd.run 20155 dev o m
In the unix script I started gdb with the command line params from eclipse, that I found in my former tryals. The call in the shell command looks like this:
gdb -nw -i mi -cd=$LVarPathExec $LVarPathExec/vlmi9506
Then IBM just gives gdb 6.0 for AIX. I found version 6.8 in the net at http://www.perzl.org/aix/index.php?n=Main.Gdb. Our Admin installed it.
I can now step through the program and watch variables. I even can write gdb-commands directly in the console-view. yabadabadooooooo
Hope that helps to others as well. Can not tell, what was really the winner-action.
But each answer gives more new questions. Now I got 3 of them.
When I start the debug config I have to click restart in the toolbar to come really in the main procedure. Is it possible to come directly in main without restarting?
On AIX our programs are first preprocessed for embedded sql. The preprocessed c-source is put in another directory. When I duble-click the line to set a breakpoint, I get the warning "unresolved breakpoint" and in the gdb-console I see, that the break is set to the preprocessed source which is wrong. Is it possible to set the breakpoints on the right source?
We are using CICS on AIX. With the xldb-Debugger and the CDCN-command of CICS we manage that debugging is started, when we come in our programs. Is it possible to get that remotely (in plink) with gdb-eclipse as well?
I wouldn't normally take a shot in the dark on a question I can't really test the answer to, but since this one has sat around for a day, I'll give it a shot. It seems from looking at:
http://wiki.eclipse.org/TM_and_RSE_FAQ#How_can_I_do_Remote_Debugging_with_CDT.3F
...that even if the CDT has changed since that wiki page was made, you should still be able to change the debug command to:
ssh remotehost gdb
instead of using TM which uses gdbserver. This will probably be slightly slower than the TM remote debugging since that actually uses a local gdb, but on the other hand this way you won't have to NFS or SMB mount your source code to make it available to the local debugger (and if you're on a LAN it probably won't matter anyhow).
There's also a reference TCF implementation for linux, which you may or may not have any luck recompiling for AIX, but it allows for remote debugging if gdbserver is otherwise not available:
http://wiki.eclipse.org/DSDP/TM/TCF_FAQ
tried also to remotly debug an aix-appl with windows eclipse-cdt-gdb.
Got blocked at the end with unix/windows path-problems. Maybe my result can help u a little further - maybe you already got it work. I'm interested in your comment. asked on eclipse news portal- following the answer of martin oberhuber (thanks again) tried dsp dd (also blocked with path problem) and set an request in eclipse bugzilla.
here the link to news:
http://www.eclipse.org/newsportal/article.php?id=406&group=eclipse.dsdp.tm
Here my bugzilla:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=252758
At the moment we still debug localy with xldb but I am trying ddd-gdb at the moment. At least locally gdb is running.