Not long ago CLion added support for Remote GDB debugging and I'm trying to set it up with Seggers's J-Link GDB server.
My setup:
VM VirtualBox running Ubuntu 16.04
J-Link drivers: V6.10
Target chip: nRF51 (ARM Cortex M0)
CLion 2016.2.2
I usually work in windows, but as CLion doesn't support remote GDB in windows I'm trying to make it work running Ubuntu in VirtualBox. I configured the debugger in CLion like shown in the image with a little help from the blog in the link above. The arguments I have used are based on the J-Link documentation (Document: UM08001) and some guessing.
GDB server setup
My problem is that when running the debugger the process just stops and CLion's console outputs:
"Could not connect to target. Please check power, connection and
settings."
I have tried to run JLinkGDBServer from the terminal and then I get as far as this:
/usr/bin/JLinkGDBServer -device nrf51422_xxAC -if swd -speed 1000 -endian little
SEGGER J-Link GDB Server V6.10 Command Line Version
JLinkARM.dll V6.10 (DLL compiled Sep 14 2016 16:46:16)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: yes
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: nrf51422_xxAC
Target interface: SWD
Target interface speed: 1000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 5 2016 08:42:09
Hardware: V1.00
S/N: 681666518
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...
Does anyone have a clue of what I'm doing wrong?
You're probably confusing GDB server and GDB itself. Those are GDB options that should be set in the GDB Remote Debug Configuration in CLion, not GDB server settings.
That is, you first run JLinkGDBServer manually, for example, from terminal, just as you've done already, and leave it waiting for GDB to attach. At this moment one should notice the connection port:
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...
Then edit your GDB Remote Debug Configuration in CLion to use the host GDB (most likely /usr/bin/gdb in your case, install it using sudo apt install gdb if necessary), and use the port mentioned above as part of the "target remote" string:
GDB: /usr/bin/gdb
"target remote" args: :2331
Notice the preceding colon in front of the port. This is a shorthand for connecting to localhost using TCP. Just in case, the explicit form is tcp:localhost:2331.
Now you can start the debug session. CLion will start the configured host GDB, GDB communicates to JLinkGDBServer through the specified TCP connection, and finally the GDB server chats with your device.
Related
I want to debug the kernel of windows server 2019. My physical host is windows 10. My
VM is windows server 2019(VirtualBox). I followed this video on youtube to complete my
setup<https://www.youtube.com/watch?v=V7DJ_ptkOpM>.
I got this on my VM which I think it's not the reason I failed
c:\KDNET>.\kdnet.exe 172.26.48.1 51111
Enabling network debugging on Intel(R) PRO/1000 MT Desktop Adapter.
Manage-bde.exe not present. Bitlocker presumed disabled.
To debug this machine, run the following command on your debugger host machine.
windbg -k net:port=51111,key=1gofrzddjdu9q.2stxhh3p9pieh.114a4fe4c4vr4.16nbo0k9ghw3v
Then reboot this machine by running shutdown -r -t 0 from this command prompt.
I run the command
windbg -k net:port=51111,key=1gofrzddjdu9q.2stxhh3p9pieh.114a4fe4c4vr4.16nbo0k9ghw3v
The result is this
Using NET for debugging
Open WinSOCKET 2.0
Failed to initialize IPv6 socket. Error On-2147467259
Will attempt to connect to IPv4 only
Failed to initialize IPv4 socket. Error On-2147467259
Kernel debugger failed initialization. HRESULT 0x80004005
unspecified error
This is probably easy but I am a noob in networks so please help!
Basically I am trying to display lidar points from my Velodyne VLP-16 on ROS installed on Ubuntu 18.04 which is in turn installed via Parallels Desktop on my macOS.
So I plugged the velodyne's ethernet cable to my MacBook via a usb-C-to-ethernet adapter and set this on my mac:
I can type in my browser this address 192.168.1.201 and I can see the velodyne interface. So it works.
When I now go to "Ubuntu on Mac" via Parallels Desktop and do not change anything in Network->Settings->Wired->Connected so I can see these settings:
... I can still see the velodyne interface via a browser on Ubuntu by typing the 192.168.1.201 address as I can on macOS.
The only problem is that when I wanna run
roslaunch velodyne_pointcloud VLP16_points.launch
it says that:
[ INFO] [1592867527.026682801]: Opening UDP socket: port 2368
[ WARN] [1592867528.028658170]: Velodyne poll() timeout
[ERROR] [1592867528.029191798]: DriverNodelet::devicePoll - Failed to poll device.
so it does not work.
I have tried to look up something similar but I failed cos my knowledge in networks is very limited. Following this tutorial I could not get this command through cos it says:
maciej#ubuntu:~$ sudo ifconfig eth0 192.168.3.100
[sudo] password for maciej:
SIOCSIFADDR: No such device
eth0: ERROR while getting interface flags: No such device
Interestingly, when I change the IP address on "Ubuntu on Mac" to this:
I cannot see the Velodyne interface in my browser on Ubuntu, but I still can on my macOS.
I will just add that when I follow the mentioned tutorial on Ubuntu installed on a PC (not via Parallels Desktop on mac), everything works.
Please help bosses!
After a thorough examination of the network traffic both on macOS and on the emulated Ubuntu using Wireshark on both ends, I realised that there is no Network adapter present in the virtual machine configuration.
Following the answer from Desktop Parallel support, I did:
Ubuntu on Mac -> configure -> hardware -> add device -> network 2 -> source: USB...
and when you check now in Wireshark, you will see the traffic coming from the USB adapter and the ROS driver, via an adequate port, will capture the packets.
I got vmlinux.uimg and vmlinux from my friend. The vmlinux is build with Linux version 4.14.10. I have two machines:
target (arm 32 bit architecture) and
host (x86 architecture)
Both systems are connected with wire, port numbers are /dev/ttySAC3 and /dev/ttyUSB0 respectively. Target boot up by reading image file vmlinux.uimg from sd card. I want to debug this vmlinux from my host machine.
The steps I am following are:
Start minicom in host.
Type
echo ttySAC3,115200 > /sys/module/kgdboc/parameters/kgdboc in minicom.
I am getting "KGDB: Registered I/O driver kgdboc".
Type
echo g >/proc/sysrq-trigger in minicom
I am getting "sysrq DEBUG and Entering KGDB".
Close minicom.
Go to vmlinux folder through terminal in host machine.
Type
gdb vmlinux
[Note: this gdb I am using is 7.10 version for arm]
In GDB type
target remote /dev/ttyUSB0
It give me a message
Remote debugging using /dev/ttyUSB0 0xc0d14f5 in sysrq_dbg_op()
In GDB type
b do_mmap_pgoff
I am getting a message
breakpoint 1 at xxxx: do_map_pgoff (4 location)
In GDB type
cont
This gives me a message
Continuing.
and then does nothing..
The problems:
GDB continue is not working as expected. I am expecting last step(9) to continue with target restart and hit the break point instead it is getting crash.
GDB step and next are not working as expected. Single stepping until exit from sysrq_dbg_op() which has no line number information. "Warning: invalid remote reply".
GDB 'run' is also not working. It display a message "The remote target does not support run"
How can I call a module on my target on which I have put breakpoint as I can not use minicom and gdb concurrently.
What all steps I should follow after I freeze the kernel.
What is wrong in this process?
I'm running a small test program on an embedded Linux target (a Freescale i.MX25), which I'd like to debug using GDB. I connect to the system using an FTDI USB-RS232 cable through am Ubuntu VM. GDBserver is installed on the target. I do not have Ethernet or USB support on the target, so I'm trying to use GDB over serial.
When I log into the target using Minicom, I get:
login[1691]: root login on 'ttymxc0'
which I presume means that the console is using ttymxc0. Then, I try to start GDBserver listening for connections from the VM to the test program, residing in /home:
$ cd /home
$ gdbserver /dev/ttymxc0 test
which gives the output (repeatedly):
Remote debugging using /dev/ttymxc0
readchar: Socket operation on non-socket
Remote side has terminated connection. GDBserver will reopen the connection
Is this an error in the way I'm trying to use GDBserver, or something else? Is there another way to debug the program?
You can not use ttymxc0 for two things at the same time (serial console and serial gdb). Disable the getty on that serial line and replace it by the gdbserver.
Does anyone had a successful experience with VirtualKD setup on Linux host running VMWare Workstation 8 (with Win7 guests)?
Despite the facts there's a lot of admiring comments about 'speed' and 'other benefits' of that VirtualKD, most of them come from Windows/VirtualBox users, and I really don't want to waste my time on trying to get it working on unsupported configuration.
P.S. Official VirtualKD forum has a similar thread that is still unanswered for two years, so decided to ask for reviews here.
P.P.S. My actual problem is that VMWare's socket-based COM port debugging is very slow.. it takes 10 to 20x more time to copy debug output from debuggee to debugger machine, than it takes to print same output to DbgView.
Does anyone had a successful experience with VirtualKD setup on Linux host running VMWare Workstation 8 (with Win7 guests)?
VirtualKD is a Windows-only application. The poster on the forum has worked around the problem of it being Windows-only by redirecting a Unix socket to TCP, therefore allowing Windows clients to connect over the network.
I've used socat to successfully bridge two VMs using a tcp socket. I created pipes in /tmp and ran socat between them; one VM can then debug the other.
In my case, because I'd configured the debugger to use serial connections I was rate limited by the serial connections. I haven't tried the VirtualKD-style setup; however, my bet is it won't work. From the VirtualKD explanation of its internals on VMWare, the client-side code is basically using hypervisor provided functionality. VirtualBox has to be patched by VirtualKD; I expect this is to provide such functionality to VirtualBox clients.
The bad news is this means, ultimately, that the Linux host hypervisor (VMware/VirtualBox on the host) must know to process that information and pass it out to the appropriate location. By default, it won't know how to do this.
I have a successful experience running it on Windows if anyone is looking for that:
Install VirtualBox 5.x or less and create a virtual machine with a Windows .iso SATA device and set it up
Download VirtualKD-3.0
Open the VM and run vminstall.exe on the guest
On admin cmd on the guest: bcdedit /dbgsettings SERIAL DEBUGPORT:1 BAUDRATE:115200
Shut down VM, close VirtualBox and kill the VBoxSVC.exe process
Run VirtualIntegration.exe. If it crashes open an admin cmd and cd to C:\Program Files\Oracle\VirtualBox and then type vboxmanage setextradata <VMNAME> VBoxInternal/Devices/VirtualKD/0/Config/Path <VirtualKD-3.0 folder> i.e. vboxmanage setextradata Windows7 VBoxInternal/Devices/VirtualKD/0/Config/Path C:\Users\lewis\Downloads\VirtualKD-3.0
Open vmmon64.exe and set the debugger path i.e C:\Program Files\Debugging Tools for Windows (x64)\windbg.exe, and then select WINDBG.EXE and start debugger automatically
Launch VM and highlight the VirtualKD entry and press f8 and disable driver signature enforcement and you will soon break into the debugger at nt!RtlpBreakWithStatusInstruction, which is a debugger symbol for the first address of the DbgBreakPointWithStatus, which is called from InitBootProcessor, which is the breakpoint you'd get from sxe ibp;.reboot. There is an earlier breakpoint of sxe ld:nt
You will need to unpatch the VM in order to be able to boot it without vmmon open. VirtualKD is good for logging with debugging protocol packets and automating windbg connection but you can't boot debug with it. In order for boot debugging to work you will need to create a COM1 serial port on the VM and set it to create a pipe \\.\pipe\pipename. You then need to connect to the pipe via windbg manually. Make sure that you have done bcdedit /bootdebug /on && bcdedit /bootdebug {bootmgr} /on && bcdedit /set {bootmgr} debugtype serial && bcdedit /set {bootmgr} baudrate 115200 && bcdedit /set {bootmgr} debugport 1 on the guest before booting.