0

Update: found a workaround - explained at the bottom

I'm trying to remote debug my program via a serial port. On the target machine (arm, linux) (connected to host machine (Windows) via serial-to-usb) I connected via Putty and looked for ttyS* in /dev directory, but I don't have any. I have only tty[num] (without the S), and running:

dmesg | grep tty

as suggested here gives the following:

# dmesg | grep tty
Kernel command line: mxc_hdmi.only_cea=0 console=ttymxc1,115200 vmalloc=400M consoleblank=0 rootwait fixrtc root=/dev/mmcblk1p1
2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 58, base_baud = 5000000) is a IMX
21e8000.serial: ttymxc1 at MMIO 0x21e8000 (irq = 59, base_baud = 5000000) is a IMX
console [ttymxc1] enabled

So I tried to use ttymxc0 and ttymxc1:

gdbserver /dev/ttymxc0 ./test/main
Process ./test/main created; pid = 253
Remote debugging using /dev/ttymxc0

and on host machine (Windows 7): (edited following comments)

gdb path/on/host/main
(gdb) target remote COM15
COM15: No such file or directory.

I see here that serial was broken at gdb 6.6, but I have gdb 7.7.

Why am I getting the No such file or directory error?

edit 2:

Although I had tried renaming the port to COM5 and it didn't help (same result), I renamed the port to COM2 and it worked for once and then it got out and stopped working:

(gdb) target remote COM2
Remote debugging using COM2
Ignoring packet error, continuing...
Malformed response to offset query, qOffsets //got out
(gdb) target remote COM2 //tried again, didn't work
COM2: No such file or directory.

The difference between COM2 and COM15 (besides the digits number) is that in Windows Device Manager COM2 appeared as "used", and COM15 (and COM5) did not. When I picked COM2 as the new name, Windows warned me that it's being used but I accepted the change anyway.

Now I cleared all COM ports and now it's working alternately (haven't succeeded actually debugging yet, but it's not falling on that "no such file or directory" error anymore).

edit 3:

So now target remote COM2 responds with "Remote debugging using COM2 , Malformed response..." when I'm not connected to the target via Putty. When I am connected via Putty, it says "COM2: No such file or directory". It's like the port is taken (by Putty) and gdb can't log into it.

I ended up connecting by TCP instead of serial line:

  • Connect target to internet by ethernet cable
  • edit /etc/network/interfaces to setup dhcp:

auto eth0

iface eth0 inet dhcp

  • run ifconfig or ip addr on target to get the ip
  • run on target:

gdbserver [ip:port] ./path/to/executable/on/target

  • run on host:

gdb path/to/executable/on/host/compiled/to/target

(gdb) target remote [target's ip:port]

This is a sufficient workaround for me.

Community
  • 1
  • 1
Alaa M.
  • 4,961
  • 10
  • 54
  • 95
  • Presumably the host machine and target machine are not identical, therefore why would you expect them to have identical serial ports? – Notlikethat Aug 29 '16 at 09:18
  • I thought I need to provide the host machine with the port name in the target machine. But I also tried `(gdb) target remote COM15` (`COM15` is the port name in the host machine) and got the same result – Alaa M. Aug 29 '16 at 09:37
  • Ah, GNU tools on Windows, that explains a lot ;) The problem will be that [you're using COM15, and GDB is not clever enough to do the right thing](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#win32_device_namespaces). – Notlikethat Aug 29 '16 at 12:08
  • I see. So the problem exists in `COM[num], num>9`. I tried `\\.\COM15` as the post suggests, and got the same result. I also tried changing the port name to `COM2`, and then `target remote COM2` => same result. – Alaa M. Aug 29 '16 at 12:15
  • It could be a .config file problem, try to see your settings in this file /proc/config.gz (this https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks, for example in serial console section) – invictus1306 Aug 29 '16 at 15:10
  • Try `target remote /dev/ttyS14` to use COM15. Also, you may need to adjust the serial port's speed to match that of the target (`set serial baud nnnnn` on the gdb side). – Mark Plotnick Aug 29 '16 at 15:14
  • @invictus1306 But the problem seems to be in the host machine, so why edit files in the target machine? – Alaa M. Aug 29 '16 at 15:23
  • @MarkPlotnick We are talking Windows...Why would COM15 be called **/dev/ttyS14** ? – Alaa M. Aug 29 '16 at 15:24
  • @AlaaM. That's the notation that Cygwin-compiled programs use. http://stackoverflow.com/questions/2899180/how-can-i-use-com-and-usb-ports-within-cygwin – Mark Plotnick Aug 29 '16 at 15:28
  • @MarkPlotnick So `COM[x]` = `ttyS[x-1]` ? Anyway it's not working... Same result. And I'm using linaro cross compiler. Does that make a difference? – Alaa M. Aug 29 '16 at 15:30
  • @AlaaM I think for this reason: tty[num] (without the S) – invictus1306 Aug 29 '16 at 15:39
  • Yes, COM[x] = ttyS[x-1]. The compiler that produces binaries that you run on the remote system won't affect the naming convention used by gdb to access the local system's serial ports. – Mark Plotnick Aug 29 '16 at 15:44
  • @MarkPlotnick OK I tried. Connecting to and disconnecting from it works via Hype!Terminal (but only when I'm not connected to it by Putty). I need to connect to it by Putty to run `gdbserver ...`. Anyway, `(gdb) target remote COM15` doesn't work in Windows cmd also when I'm not connected to the port via Putty (neither does `target remote /dev/ttyS14`) – Alaa M. Aug 29 '16 at 15:49

0 Answers0