Closed opensw closed 5 years ago
@opensw What is your current OS?
@opensw So I tested this on Ubuntu 16.04 and tried remote to another Linux machine I had running Centos:
I can't duplicate this at all. I created a program with function calls and a loop and I start the debugger. I set a breakpoint as its running in the main loop and it breaks immediately when it is hit.
I set stopAtEntry
to be true and it stops on my very first line in main.cpp
.
See the first point, I can't duplicate this one either
Are you saying that when you do this, it attaches and doesn't run? If you are specifying setupCommands, it will expect you to issue all your setup commands, so you may want to add one that is -exec-run
.
The only thing I can think of is that you are not compiling with the -g
flag? Otherwise if you give me more information I can try and duplicate it. If you use pipeTransport
and ssh
to connect to the gdb
instance on your device, does it work properly?
Hello there :)
At work I have Kubutnu 16.04 (it is essentially the same like yours).
The only thing I can think of is that you are not compiling with the -g flag?
I am using makefile and the flag is set to -og (it is the same like -o0 -g).
To reply to your 1th, 2th and 3th point With standard gcc, gdb and gdbserver is working properly, my issues are with remote debugging on arm on Yocto distro. To replicate the issues you need:
Maybe you do not need zynq7 hardware, maybe it is possible to replicate this also with qemux86 (I can check at work) and core-image-minimal.
About 4th I cannot start gdbserver in anyways with pipeTransport.
If you use pipeTransport and ssh to connect to the gdb instance on your device, does it work properly?
No, it is not working.
P.S. I can debug the application with Qt Creator and Eclipse CDT, I applied the same logic to Visual Studio Code:
@opensw What do you get when you use the pipeTransport
block with SSH? I assume that you have gdb on the target device, this should allow you to debug as if you are on the device with actual gdb on the arm device. I'll see if I can find some hardware to try this but I don't think I have the hardware to try your specific scenario. Can you enable in your launch.json
:
"logging": { "engineLogging": true }
and send me the log of you trying the breakpoint scenarios?
"What do you get when you use the pipeTransport block with SSH?"
A crash, tomorrow at work I will try again but before to do it I have some questions: 1) With pipeTransport, will cpptools copy to the target the file specified in "program" field of launch.js? If no, I need to copy it manually via ssh but how does pipeTransport know where I copied it (to run properly gdb)? 2) On target device, do I need to copy also the source code and use sourceMap option? 3) I am guessing that pipeTransport run gdb on target device and do not use gdbserver (on target device) and gdb (in this case a custom gdb for xilinx-zynq7) on host machine too, am I right? It is just to understand how pipeTransport is working; 4) Is my followwing configuration for pipeTransport fine or I need to change something?
"pipeTransport": { "pipeCwd": "${workspaceRoot}",// local cwd "pipeProgram": "/usr/bin/ssh", // local ssh "pipeArgs": ["root@192.168.0.10"], // remote device "debuggerPath": "/usr/bin/gdb" // remote path },
Thank you :)
@opensw
"cwd"
and "program"
fields with the path that they are on the remote device. pipeTransport
uses ssh and we get the gdb
MI commands through stdin and stdout. Our debug adapter uses that for debugging. If you enable the "logging"
section I specified above you can see the MI Commands we send gdb and the responses it gets back. "pipeArgs"
you may need to specify authentication method such as your private key or a password to connect. you can test it by running the "pipeProgram"
+ "pipeArgs"
from a console window and seeing if it connects. if you get a bash
prompt then you have it right. Hi, with pipeTransport it is worst then the previous method with my launch.js: 1) Cannot stop at main; 2) Cannot stop at any breakpoints (before/after gdb is running).
I do not know, until I will not find a solution I will use Qt Creator for debugging.
Cheers
And for log, unfortunately is not possible to copy full text from Visual Studio Code Debug Console, I have selected only the relevant part reported as followed:
`1: (144) LaunchOptions<PipeLaunchOptions xmlns='http://schemas.microsoft.com/vstudio/MDDDebuggerOptions/2014'
1: (150) LaunchOptions ExePath='/home/root/tcp-serv'
1: (150) LaunchOptions WorkingDirectory='/home/root/'
1: (150) LaunchOptions ExeArguments=''
1: (150) LaunchOptions MIMode='gdb'
1: (151) LaunchOptions PipePath='/usr/bin/ssh'
1: (151) LaunchOptions PipeArguments='root@192.168.0.10 /usr/bin/gdb --interpreter=mi'
1: (151) LaunchOptions PipeCwd='/home/paolo/Dev/ps-yocto/meta-psfast/recipes-psfast/tcp-server-fields/tcp-server-fields'
1: (151) LaunchOptions>
1: (151) LaunchOptions
=thread-group-added,id="i1"
GNU gdb (GDB) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-poky-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word".
=cmd-param-changed,param="auto-load safe-path",value="/"
1: (521) <-1009-exec-run
1: (522) ->=thread-group-started,id="i1",pid="1477"
1: (523) ->=thread-created,id="1",group-id="i1"
1: (532) ->=library-loaded,id="/lib/ld-linux.so.3",target-name="/lib/ld-linux.so.3",host-name="/lib/ld-linux.so.3",symbols-loaded="0",thread-group="i1"
1: (536) ->&"Cannot access memory at address 0x0\n"
1: (536) ->1009^running
1: (536) ->running,thread-id="all"
1: (536) 1009: elapsed time 15
1: (536) ->(gdb)
1: (538) ->~"Stopped due to shared library event (no libraries added or removed)\n"
Stopped due to shared library event (no libraries added or removed)
1: (539) ->stopped,reason="solib-event",thread-id="1",stopped-threads="all",core="1"
1: (544) <-1010-interpreter-exec console "info sharedlibrary"
1: (545) ->~"From To Syms Read Shared Object Library\n"
1: (546) ->~"0x4a0907c0 0x4a0ab510 Yes /lib/ld-linux.so.3\n"
1: (546) ->1010^done
1: (546) ->(gdb)
1: (546) 1010: elapsed time 2
Loaded '/lib/ld-linux.so.3'. Symbols loaded.
1: (548) <--exec-continue
1: (548) ->^running
1: (548) ->running,thread-id="all"
1: (549) ->(gdb)
1: (557) ->=library-loaded,id="/usr/lib/libstdc++.so.6",target-name="/usr/lib/libstdc++.so.6",host-name="/usr/lib/libstdc++.so.6",symbols-loaded="0",thread-group="i1"
1: (558) ->=library-loaded,id="/lib/libm.so.6",target-name="/lib/libm.so.6",host-name="/lib/libm.so.6",symbols-loaded="0",thread-group="i1"
1: (559) ->=library-loaded,id="/lib/libgcc_s.so.1",target-name="/lib/libgcc_s.so.1",host-name="/lib/libgcc_s.so.1",symbols-loaded="0",thread-group="i1"
1: (560) ->=library-loaded,id="/lib/libpthread.so.0",target-name="/lib/libpthread.so.0",host-name="/lib/libpthread.so.0",symbols-loaded="0",thread-group="i1"
1: (561) ->=library-loaded,id="/lib/libc.so.6",target-name="/lib/libc.so.6",host-name="/lib/libc.so.6",symbols-loaded="0",thread-group="i1"
1: (716) ->&"warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.\n"
1: (748) ->~"Stopped due to shared library event:\n"
Stopped due to shared library event:
1: (748) ->~" Inferior loaded /usr/lib/libstdc++.so.6\n"
Inferior loaded /usr/lib/libstdc++.so.6
1: (748) ->~" /lib/libm.so.6\n"
1: (748) ->~" /lib/libgcc_s.so.1\n"
/lib/libm.so.6
/lib/libgcc_s.so.1
1: (748) ->~" /lib/libpthread.so.0\n"
/lib/libpthread.so.0
1: (748) ->~" /lib/libc.so.6\n"
/lib/libc.so.6
1: (748) ->stopped,reason="solib-event",added=[library="/usr/lib/libstdc++.so.6",library="/lib/libm.so.6",library="/lib/libgcc_s.so.1",library="/lib/libpthread.so.0",library="/lib/libc.so.6"],thread-id="1",stopped-threads="all",core="0"
1: (749) <-1011-interpreter-exec console "info sharedlibrary"
1: (751) ->~"From To Syms Read Shared Object Library\n"
1: (751) ->~"0x4a0907c0 0x4a0ab510 Yes /lib/ld-linux.so.3\n"
1: (752) ->~"0x4a776bc8 0x4a7e2e6c Yes /usr/lib/libstdc++.so.6\n"
1: (752) ->~"0x4a36bc40 0x4a39e140 Yes /lib/libm.so.6\n"
1: (752) ->~"0x4a22d160 0x4a23ba90 Yes /lib/libgcc_s.so.1\n"
1: (752) ->~"0x4a1fc1e0 0x4a20a6e8 Yes /lib/libpthread.so.0\n"
1: (752) ->~"0x4a0d7040 0x4a1c8b00 Yes /lib/libc.so.6\n"
1: (752) ->1011^done
1: (752) ->(gdb)
1: (752) 1011: elapsed time 3
Loaded '/usr/lib/libstdc++.so.6'. Symbols loaded.
Loaded '/lib/libm.so.6'. Symbols loaded.
Loaded '/lib/libgcc_s.so.1'. Symbols loaded.
Loaded '/lib/libpthread.so.0'. Symbols loaded.
Loaded '/lib/libc.so.6'. Symbols loaded.
1: (753) <--exec-continue
1: (753) ->^running
1: (754) ->running,thread-id="all"
1: (754) ->(gdb)
1: (756) ->Address map constructor
Address map constructor
1: (756) ->address low: 40000000
address low: 40000000
1: (757) ->address high: 43c00000
1: (757) ->hardware constructor
address high: 43c00000
hardware constructor
1: (760) ->=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00017510",at="
@opensw So I tried a hello world app on Raspbian OS on a RaspberryPi3 running GDB version 7.7.1 and I can't duplicate any of the breakpoint issues. I can set breakpoints while running, pause (break all) into code and stop. I wasn't able to set stopAtEntry so I am looking into that scenario.
I tried yocto on the Pi but it doesn't have gdb or g++ to compile and I didn't have the time to find and figure it out. I'm afraid this seems to be an issue with gdb on the yocto image. The layer that does the translation for us is called MIEngine and is open source and you are welcome to download it and try and figure out why it doesn't work for that distribution but since it isn't supported and I can't duplicate it, I'm limited in how much more I can help.
Hi, thank you for your debugging effort :)
I tried yocto on the Pi but it doesn't have gdb or g++ to compile and I didn't have the time to find and figure it out
If you are using poky 2.2, set in poky-morty-16.0.0/build/conf/local.conf EXTRA_IMAGE_FEATURES ?= "debug-tweaks tools-debug eclipse-debug" to include gdb, gbserver etc.
For gcc etc you need to install the toolchain on local machine (to generate the toolchain you need to use bitbake meta-toolchain or similar for your platform). After this step you need to source toolchain environment, start Visaul Studio Code from the same console, build, deploy to remote device, start debugging session. I know, it is too long to set everything, if you really have time I can write you all steps in details for your platform.
Maybe the issue is related only to my launch.js file because with Qt Creator and Eclipse CDT I am able to debug remotely the applications (I set same gdb, gdbserver etc).
@opensw I was able to get it setup on the Raspberry Pi. there were a few issues surrounding stopAtEntry that I fixed but the set breakpoint or pause items I was not able to duplicate. Please find below a copy of the launch.json
I created to test this. The fixes should be in the next release. This configuration should work and I added comments in it to help clarify:
{
"version": "0.2.0",
"configurations": [
{
"name": "C++ Launch (gdbserver)",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/a.out", // Local copy of the executable
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceRoot}", // Local working directory
"environment": [],
"externalConsole": true,
"miDebuggerServerAddress": "10.10.10.10:2323", //remote server address
"miDebuggerPath": "/usr/bin/arm-none-eabi-gdb",
"linux": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
"logging": {
"engineLogging": true
},
"sourceFileMap": {
"/src/hello_world": "/src/hello" // Compile time source location: Local source location
}
},
{
"name": "C++ Launch (ssh)",
"type": "cppdbg",
"request": "launch",
"program": "/src/hello_world/a.out", // Executable on the remote machine
"args": [],
"stopAtEntry": true,
"cwd": "/src/hello_world", // Directory on remote machine
"environment": [],
"externalConsole": true,
"sourceFileMap": {
"/src/hello_world": "/src/hello" // "Compile time source location": "local source location"
},
"pipeTransport": {
"pipeCwd": "/usr/bin", // Local directory of pipe program
"pipeProgram": "ssh", // Pipe program
"pipeArgs": ["root@10.10.10.10"],
"debuggerPath": "/usr/bin/gdb" // Debugger location on the remote machine
}
}
]
}
Good morning, I really appreciate your efforts to reproduce the issues, thank you a lot.
I adapted your launch.js to my setup but I have the same issues with breakpoints (for "C++ Launch (gdbserver)" and "C++ Launch (ssh)" too).
The only relevant difference between my configuration and yours is the target device, then:
1) For compiler I have this setting "arm-poky-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a9 --sysroot=/opt/poky/1.8/sysroots/cortexa9-vfp-neon-poky-linux-gnueabi -D_CAENELS_FASTPS_ -std=c++14 -og -c -o objs/tcp-serv.o tcp-serv.cpp"
;
2) For local and remote debugger I am using for gdb/gdbserver the arm version from xilinx zynq7 (cortex-a9).
I am guessing the issue is related to the gdb/gdbserver arm version, in the next weeks I am planing to do a migration to poky2.2 that is more recent than my current poky1.8; maybe the last release does not have this issue, I hope.
Cheers Paolo
@opensw I'm compiling on the device itself with the compiler that is included during the build.
I made this line EXTRA_IMAGE_FEATURES ?= "debug-tweaks tools-debug tools-sdk eclipse-debug"
and it installs G++ according to the information for tools-sdk
@pieandcakes I have just gave another try to Visual Studio Code (last release with last cpptools) and I do not have anymore the above issue. Nice.
Hello there, I am trying to use Visual Studio Code 1.9.1 and cpptools 0.10.1 to debug an embedded application on a remote device (Yocto distro); following the behavior of the debugger: 1) If I do not put manually any breakpoints before to start the debugging session then it is not possible to stop in anyway the application at breakpoints added during runtime; 2) When I start a debugging session, the debugger cannot stop automatically when enters in the main function; 3) If I put manually some breakpoints before to start debugging session then the debugger stops correctly at added breakpoints, but if I add some breakpoints during runtime (when the application is running) then the debugger cannot stop at this new breakpoints; 4) Minor issue, it is not possible to run automatically gdbserver when I set in launch.js MIDebuggerServerAddress and related options.
To summary, it is not possible add breakpoints when the application is running, the debugger skips them.
Following is my launch.js and debugging info about debugger (point 1).
{ "version": "0.2.0", "configurations": [ { "name": "C++ Launch", "type": "cppdbg", "request": "launch",
}
1: (301) LaunchOptions<LocalLaunchOptions mlns='http://schemas.microsoft.com/vstudio/MDDDebuggerOptions/2014' 1: (317) LaunchOptions ExePath='/home/paolo/Dev/ps-yocto/meta-psfast/recipes-psfast/tcp-server-fields/tcp-server-fields/tcp-serv' 1: (317) LaunchOptions WorkingDirectory='/home/paolo/Dev/ps-yocto/meta-psfast/recipes-psfast/tcp-server-fields/tcp-server-fields' 1: (317) LaunchOptions ExeArguments='' 1: (317) LaunchOptions MIMode='gdb' 1: (317) LaunchOptions MIDebuggerPath='/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb' 1: (317) LaunchOptions WaitDynamicLibLoad='false' 1: (317) LaunchOptions ExternalConsole='true' 1: (318) LaunchOptions> 1: (318) LaunchOptions <SetupCommands> 1: (318) LaunchOptions <Command IgnoreFailures='false' Description=''>target remote 192.168.0.10:3333</Command> 1: (318) LaunchOptions </SetupCommands> 1: (319) LaunchOptions</LocalLaunchOptions> 1: (463) TempFile=/tmp/Microsoft-MIEngine-fifo-b38xy7uy.smk 1: (464) TempFile=/tmp/Microsoft-MIEngine-fifo-e656n0hl.q3k 1: (464) TempFile=/tmp/Microsoft-MIEngine-fifo-q20okmiv.le0 1: (593) ShellPid=27441 1: (625) DebuggerPid=27445 1: (746) ->=thread-group-added,id="i1" 1: (748) ->~"GNU gdb (GDB) 7.8.1\n" 1: (748) ->~"Copyright (C) 2014 Free Software Foundation, Inc.\n" 1: (748) ->~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\n" 1: (748) ->~"This GDB was configured as \"--host=x86_64-pokysdk-linux --target=arm-poky-linux-gnueabi\".\nType \"show configuration\" for configuration details." 1: (748) ->~"\nFor bug reporting instructions, please see:\n" 1: (748) ->~"<http://www.gnu.org/software/gdb/bugs/>.\n" 1: (748) ->~"Find the GDB manual and other documentation resources online at:\n<http://www.gnu.org/software/gdb/documentation/>.\n" 1: (748) ->~"For help, type \"help\".\n" 1: (748) ->~"Type \"apropos word\" to search for commands related to \"word\".\n" 1: (748) ->=cmd-param-changed,param="auto-load safe-path",value="/" 1: (749) ->(gdb) 1: (755) <-1001-gdb-set target-async on 1: (762) ->1001^done 1: (762) ->(gdb) 1: (763) 1001: elapsed time 9 1: (782) <-1002-interpreter-exec console "target remote 192.168.0.10:3333" 1: (785) ->~"Remote debugging using 192.168.0.10:3333\n"