Im very New to KGDB, Im getting problem when im connecting the target from Host, Getting The following Error.
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
Ignoring packet error, continuing...
warning: unrecognized item "swreak" in "qSupported" response
warning: unrecognized item "ReloInsn" in "qSupported" response
warning: unrecognized item "QTread'
[3]kdb> " in "qSupported" response
Bogus trace status reply from target: qTStatus
...
#
The Procedure Im following is :
[Target] stty -F /dev/ttyS0 115200
[Host] stty -F /dev/ttyUSB0 115200
Make sure the serial connection works on both direction. You can use:
[Host] cat /dev/ttyUSB0
[Target] echo 'from TARGET to HOST' > /dev/ttyS0
[Target] cat /dev/ttyS0
[Host] echo 'from HOST to TARGET' > /dev/ttyUSB0
You should see the messages on both side of machine. If not, there
might be some problems on the cable or driver.
Compile Kernel
Enable KGDB* , KGDB_SERIAL*, KGDB_USB*, DEBUG_INFO, DEBUG_INFO_DWARF4,
MAGIC_SYSRQ in the kernel config. Compile and install on the TARGET.
The main purpose here is to enable KGDB feature & preserve debug
information in vmlinux.
agent-proxy Setup
agent-proxy acts as a proxy for the TARGET's serial port. It splits up
the serial port for multiplexing. One for primary console I/O, the
other for GDB session. Thus, we can work on both simultaneously. You
should run the agent-proxy on HOST machine.
git clone http://git.kernel.org/pub/scm/utils/kernel/kgdb/agent-proxy.git
cd agent-proxy ; make
./agent-proxy 5550^5551 0 /dev/ttyUSB0,115200
This will redirect:
TARGET's console to HOST:5550
TARGET's kgdb listening port to HOST:5551
Start To Debug
First, open the primary console:
[Host] telnet localhost 5550
Entering the kdb mode, either by:
[Target] echo ttyS0,115200 > /sys/module/kgdboc/parameters/kgdboc
[Target] dmesg | tail
(you should see KGDB: Registered I/O driver kgdboc, otherwise it
failed)
[Target] echo g >/proc/sysrq-trigger
Host> gdb vmlinux
(gdb) target remote localhost:5551
Remote debugging using localhost:5551
kgdb_breakpoint () at kernel/debug/debug_core.c:1072
1072 wmb(); /* Sync point after breakpoint */
(gdb)
#
when i type kgdb in target mission it is getting error as Permission denied as shown below
[3]kdb> kgdb
diag: -22: Permission denied
..., I would appreciate the clear answer in steps..., Thanks in advance
diag: -22: Permission denied
That error means that access to debugger functions is prohibited by default in you kernel. In order to unlock debugger you need exec this command:
echo 1 > /sys/module/kdb/parameters/cmd_enable
or add a Kernel Boot Parameter:
kdb.cmd_enable=1
More info here
Related
So I have been trying to connect with the remote server using vscode but getting this error. I can connect with the remote server using powershell as administrator. I also made sure to add the correct path to my config file. I have also deleted the config and known host files before creating new connection. What am I missing? Thanks in advance!
[21:16:19.622] Log Level: 2
[21:16:19.626] remote-ssh#0.70.0
[21:16:19.626] win32 x64
[21:16:19.627] SSH Resolver called for "ssh-remote+ec2-3-110-180-100.ap-south-1.compute.amazonaws.com", attempt 1
[21:16:19.628] "remote.SSH.useLocalServer": false
[21:16:19.628] "remote.SSH.showLoginTerminal": true
[21:16:19.629] "remote.SSH.remotePlatform": {}
[21:16:19.629] "remote.SSH.path": undefined
[21:16:19.629] "remote.SSH.configFile": C:\Users\ASUS\.ssh\config
[21:16:19.629] "remote.SSH.useFlock": true
[21:16:19.630] "remote.SSH.lockfilesInTmp": false
[21:16:19.630] "remote.SSH.localServerDownload": auto
[21:16:19.630] "remote.SSH.remoteServerListenOnSocket": true
[21:16:19.630] "remote.SSH.showLoginTerminal": true
[21:16:19.631] "remote.SSH.defaultExtensions": []
[21:16:19.634] "remote.SSH.loglevel": 2
[21:16:19.635] "remote.SSH.serverPickPortsFromRange": {}
[21:16:19.635] "remote.SSH.enableDynamicForwarding": true
[21:16:19.635] "remote.SSH.serverInstallPath": {}
[21:16:19.637] SSH Resolver called for host: ec2-3-110-180-100.ap-south-1.compute.amazonaws.com
[21:16:19.637] Setting up SSH remote "ec2-3-110-180-100.ap-south-1.compute.amazonaws.com"
[21:16:19.664] Using commit id "899d46d82c4c95423fb7e10e68eba52050e30ba3" and quality "stable" for server
[21:16:19.669] Install and start server if needed
[21:16:21.362] Checking ssh with "ssh -V"
[21:16:21.403] > OpenSSH_for_Windows_8.1
[21:16:21.403] > p1, LibreSSL 3.0.2
[21:16:21.408] Using SSH config file "C:\Users\ASUS\.ssh\config"
[21:16:21.408] Running script with connection command: ssh -T -D 7767 -F "C:\Users\ASUS\.ssh\config" "ec2-3-110-180-100.ap-south-1.compute.amazonaws.com" bash
[21:16:21.412] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[21:16:21.779] > ]0;C:\WINDOWS\System32\cmd.exe
[21:16:21.779] Got some output, clearing connection timeout
[21:16:21.798] >
> [21:16:22.159] > The authenticity of host 'ec2-3-110-180-100.ap-south-1.compute.amazonaws.
> com (3.110.180.100)' can't be established.
> ECDSA key fingerprint is SHA256:XkSx5IvSMQVKMuqzN5gAWTlM8xGAXvqQh40DubYUk
sk.
> Are you sure you want to continue connecting (yes/no/[fingerprint])?
[21:16:24.233] > y
[21:16:24.427] > e
[21:16:24.813] > s
[21:16:27.069] >
[21:16:27.090] > Warning: Permanently added 'ec2-3-110-180-100.ap-south-1.compute.amazonaw
> s.com,3.110.180.100' (ECDSA) to the list of known hosts.
[21:16:27.422] > Load key "D:\\unive\\unive-bitnami.pem": Permission denied
[21:16:27.442] > bitnami#ec2-3-110-180-100.ap-south-1.compute.amazonaws.com: Permission de
> nied (publickey).
> The process tried to write to a nonexistent pipe.
>
[21:16:28.730] "install" terminal command done
[21:16:28.731] Install terminal quit with output: nied (publickey).
[21:16:28.732] Received install output: nied (publickey).
[21:16:28.733] Failed to parse remote port from server output
[21:16:28.735] Resolver error: Error:
at Function.Create (c:\Users\ASUS\.vscode\extensions\ms-vscode-remote.remote-ssh-0.70.0\out\extension.js:1:430425)
at Object.t.handleInstallOutput (c:\Users\ASUS\.vscode\extensions\ms-vscode-remote.remote-ssh-0.70.0\out\extension.js:1:429068)
at Object.t.tryInstall (c:\Users\ASUS\.vscode\extensions\ms-vscode-remote.remote-ssh-0.70.0\out\extension.js:1:524212)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at async c:\Users\ASUS\.vscode\extensions\ms-vscode-remote.remote-ssh-0.70.0\out\extension.js:1:487216
at async Object.t.withShowDetailsEvent (c:\Users\ASUS\.vscode\extensions\ms-vscode-remote.remote-ssh-0.70.0\out\extension.js:1:490561)
at async Object.t.resolve (c:\Users\ASUS\.vscode\extensions\ms-vscode-remote.remote-ssh-0.70.0\out\extension.js:1:488295)
at async c:\Users\ASUS\.vscode\extensions\ms-vscode-remote.remote-ssh-0.70.0\out\extension.js:1:564197
[21:16:28.743] ------
I have a docker container running with -p 2000:2000, which is running a gdbserver on port 2000.
When trying to connect from my host machine through gdb I get the following:
(gdb) target remote localhost:2000
Remote debugging using localhost:2000
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
The application running in the docker container is written in C++, behind a fcgi (gdbserver :2000 spawn-fcgi -p 8000 -n ./myBinary)
Host
OS: osx
gdb version: 8.0.1 (installed with --with-all-targets)
Container
OS: ubuntu 14.04
gdb version: 7.7.1
Any help would be appreciated.
i meet the same question ,when i run my qemu ,and i want connect gdb with qemu inner gdbserver.
i do the follow job:
run qemu in system mode.
run gdbserver inside qemu
run gdb in Host computer and connect gdbservr inside gdb.
the software version are below:
QEMU emulator version 2.12.92
gdb 7.11.1
GNU gdbserver (GDB) 7.8
at first i cannot connect gdbserver,the error is
(gdb) target remote 192.168.240.136:1234
Remote debugging using 192.168.240.136:1234
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
i solve the problem by change to high level kernel when start start qemu. from vmlinux-2.6.32-5-4kc-malta to vmlinux-3.2.0-4-4kc-malta,then the command start qemu changed to below:
sudo qemu-system-mips -M malta \
-kernel vmlinux-3.2.0-4-4kc-malta \
-hda debian_squeeze_mips_standard.qcow2 \
-append "root=/dev/sda1 console=tty0" \
-net nic,macaddr=00:16:3e:00:01:01 \
-net tap \
-nographic
then the error was solved ,i can connect gdbserver with gdb.
the possible solve ways also include
bash setting
conflict
serial setting error
I am having issues with serial and usb connection between host and target. Below is my setup. Both host and target do NOT have any serial (DB9) ports.
Host : Running windows + VMshare + Ubuntu
Target: Running linux kernel 3.19 . Has a MINI usb port which acts as a serial port, i think its ( CP210x uart to usb )
Connection 1 : Host ( USB to DB9 male-PL2303) + DB9 female to female + (DB9 male to USB) target.
Connection 2 : Host ( USB ) --cable-- (USB mini) Target
Host ( ubuntu VM ), can recognize the USB device (both connections types ) as /dev/ttyUSB0. The device does not show up on the windows device manager since VM takes over the device control.
Target boots into UEFI shell. I modify the syslinux.cfg file to append "kgdbwait kgdboc =ttyS0, 115200" to APPEND flag. Save the change ( press F2) then exit ( press F3 ). Boot into the image. Target now enters the kdb prompt with the following message
kgdb: Waiting for connection from remote gdb...
Entering kdb ( current= <64bit address>, pid 1) on processor 0 due to Keyboard Entry
Kgdb > _
on the host side, i do the following commands and below is error
root#ubuntu: cd /images
root#ubuntu: sudo gdb ./vmlinux
Reading symbols from ./vmlinux done.
(gdb)
(gdb) target remote /dev/ttyUSB0
Remote debugging using /dev/ttyUSB0
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Bogus trace status reply from target: timeout
Experiments i tried
on Host i used " target remote /dev/ttyS0 " , still same issue
Tried different cables in each connection ( 1 and 2 ) mentioned above
on Target removed the edit in the syslinux.cfg file in UEFI shell, booted the image and entered kgdb using "echo g > /proc/sysrq-trigger"
All kernel configuration related to KGDB* , KGDB_SERIAL*, KGDB_USB* are enabled
all available baud rates
Questions
If i use "kgdbwait kgdboc=ttyUSB0, 115200" instead of " kgdbwait kgdboc=ttyS0, 115200" the target does NOT halt. When the target boots up fully to login prompt, i can see the device is recognized as ttyUSB0 when using connection 1. However as it does not stop does that mean, KGDB using USB does not work ? or for USB debug , i need to use direct USB--USB wire ( connection 3 ) ?
does syslinux.cfg support USB debug? becuase there is a SERIAL flag which has value" 0, 115200 " where 0 refers to ttyS0. syslinux documentation does not have any values for USB type device.
using connection 2, why am i seeing the timeout and packet error issues
occasionally with connection 2, when i execute " target remote /dev/ttyUSB0 " on the host, i notice junk characters on the target. So there is some communication happening, so tried different baud rates still same issue. Does this indicate anything inherently wrong with my setup?
In many online forums/ documents i do not see the "entering kdb due to keyboard entry" when the kernel enters kdb prompt. is this unusual?
The setup of remote kgdb debug is a bit tedious. There are several prerequisites/limitations for the kgdb to work. I will try to break it down.
You have to prepare two machines in this setup.
HOST: Where the agent-proxy & GDB installed.
TARGET: The Linux system being debugged.
Connection Setup
[Host /dev/ttyUSB0] USB to Serial --------- COM port [Target /dev/ttyS0]
On the TARGET side, it's not possible to use the USB interface with kgdb. This is because all the USB-Serial driver (CP210x, PL2303, ...etc) did not implement the polling hook. You have to connect the COM port with a serial cable directly. It is ok to use the USB interface on the HOST side. Since it is a serial connection, you have to use a USB-to-Serial converter and install the proper driver on HOST.
Set the proper baud rate on both sides:
[Target] stty -F /dev/ttyS0 115200
[Host] stty -F /dev/ttyUSB0 115200
Make sure the serial connection works on both direction. You can use:
[Host] cat /dev/ttyUSB0
[Target] echo 'from TARGET to HOST' > /dev/ttyS0
[Target] cat /dev/ttyS0
[Host] echo 'from HOST to TARGET' > /dev/ttyUSB0
You should see the messages on both side of machine. If not, there might be some problems on the cable or driver.
Compile Kernel
Enable KGDB* , KGDB_SERIAL*, KGDB_USB*, DEBUG_INFO, DEBUG_INFO_DWARF4, MAGIC_SYSRQ in the kernel config. Compile and install on the TARGET.
The main purpose here is to enable KGDB feature & preserve debug information in vmlinux.
agent-proxy Setup
agent-proxy acts as a proxy for the TARGET's serial port. It splits up the serial port for multiplexing. One for primary console I/O, the other for GDB session. Thus, we can work on both simultaneously. You should run the agent-proxy on HOST machine.
git clone http://git.kernel.org/pub/scm/utils/kernel/kgdb/agent-proxy.git
cd agent-proxy ; make
./agent-proxy 5550^5551 0 /dev/ttyUSB0,115200
This will redirect:
TARGET's console to HOST:5550
TARGET's kgdb listening port to HOST:5551
Start To Debug
First, open the primary console:
[Host] telnet localhost 5550
Entering the kdb mode, either by:
[Target] echo ttyS0,115200 > /sys/module/kgdboc/parameters/kgdboc
[Target] dmesg | tail
(you should see KGDB: Registered I/O driver kgdboc, otherwise it failed)
[Target] echo g >/proc/sysrq-trigger
Or, by adding the following kernel parameters in TARGET's bootloader (for early kernel debug):
console=tty0 console=ttyS0,115200 kgdbwait kgdboc=ttyS0,115200
The TARGET machine will halt immediately once it breaks into the kdb.
At the same time, you will see a kdb prompt on the primary console:
....
Entering kdb (current=0xcb846c80, pid 2301) on processor 3 due to Keyboard Entry
[3]kdb>
Type kgdb then enter. The TARGET is now pending for remote GDB's connection. We will connect it from the HOST.
Host> gdb vmlinux
(gdb) target remote localhost:5551
Remote debugging using localhost:5551
kgdb_breakpoint () at kernel/debug/debug_core.c:1072
1072 wmb(); /* Sync point after breakpoint */
(gdb)
Enjoy your kernel debugging!
I used to the St-write to burn .bin to the STM32F4 and saw the message which I expected. Now, I hope to understand how GPIO init. Hence, I use OpenOCD and arm-none-eabi-gdb to do that. Here, it is my process.
$ minicom
$ openocd -f /opt/openocd/share/openocd/scripts/board/stm32f4discovery.cfg
$ arm-none-eabi-gdb main.elf
(gdb) target remote localhost:3333
(gdb) localhost:3333: Connection timed out.
How do I check the port of OpenOCD? Why does it occur timeout?
That certainly means that openocd did not start or that the port is busy.
Usually, you use :
openocd -f board/stm32f4discovery.cfg
You should check that your session is running.
Are you running a virtual linux machine on a windows host?
If so, you probably need to replace localhost with 10.0.0.2 (or whatever your windows IP is).
A good way to know, is to telnet to the openOCD address and port 4444 and see if you get the openOCD prompt, and can type a few commands.
I am trying to debug a device driver which is crashing the kernel on a Mac using a remote machine running gdb (trying to follow the instructions here). Both machines are connected to the same network by Ethernet (same router even, and both can access the network). I have also set nvram boot-args="debug=0x144" on the target and restarted.
I then load the kernel extension on the target as usual. On the host machine I start gdb like this:
$ gdb -arch i386 /Volumes/KernelDebugKit/mach_kernel
Once in gdb, I load the kernel macros and set up for remote attachment
(gdb) source /Volumes/KernelDebugKit/kgmacros
(gdb) target remote-kdp
(gdb) kdp-reattach 11.22.33.44
However, the last command then does not make a connection and I get an endless spool of
kdp_reply_wait: error from kdp_receive: receive timeout exceeded
kdp_transaction (remote_connect): transaction timed out
kdp_transaction (remote_connect): re-sending transaction
What is the correct way to get gdb connected to the target machine?
There are a number of ways to break into the target, including:
Kernel panic, as stated in your answer above.
Non-maskable interrupt, which is triggered by the cmd-option-ctrl-shift-esc key combination.
Code a break in your kernel extension using PE_enter_debugger(), which is declared in pexpert/pexpert.h
Halt at boot by setting DB_HALT (0x01) in the NVRAM boot-args value.
Additionally, you may need to set a persistent ARP table entry, as the target is unable to respond to ARP requests while stopped in the debugger. I use the following in my debugger-launch shell script to set the ARP entry if it doesn't already exist:
if !(arp -a -n -i en0 | grep '10\.211\.55\.10[)] at 0:1c:42:d7:29:47 on en0 permanent' > /dev/null) ; then
echo "Adding arp entry"
sudo arp -s 10.211.55.10 00:1c:42:d7:29:47
fi
Someone more expert could probably improve on my bit of shell script.
All of the above is documented in http://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/KernelProgramming.pdf.
The answer is simply to make sure the target has a kernel panic before you try to attach gdb from the host.