Hi,
I’m not able to start a debug session with Developer Studio 5.3.1.
I manage to build and run my application ‘test’.
When I start a debug session, the task ‘Reset gdb’ is executed fine, but, the task ‘Configure gdb’ fails.
The detailed info indicates that the gdbCfg command is called with DOUBLE arguments!
/legato/systems/current/bin/gdbCfg testtest
gdbCfg only expects the app name as an argument, but, DS sends the app name 2 times.
(( /legato/systems/current/bin/gdbCfg test --reset ) || true)
Process exited with 0
Configure gdb
/legato/systems/current/bin/gdbCfg test test
Process exited with 1
Process output:
NAME:
gdbCfg - Modify an app’s sandbox to make it suitable to run gdbserver.
SYNOPSIS:
gdbCfg appName
gdbCfg appName --reset
DESCRIPTION:
gdbCfg appName
Make gdbserver available in the /bin directory of the sandbox of an app.
gdbCfg appName --reset
Undo what "gdbCfg appName" does.
gdbCfg --help
Display this help and exit.
Does it work with official SDK for WP76 Release 9?
By the way, you can give a chance to the “attach to running process” mode (since it doesn’t need gdbCfg to run). But maybe it doesn’t fit your need… (e.g. if you want to debug really early steps of your app)
Debugging with DS 5.3.1 works fine when I use the official SDK for WP76 R9.
Debugging does not work anymore when I use a Custom Legato package as Target Platform.
I did some tests with Custom Legato builds based upon legato releases 18.04 and 18.08, but, they behave the same.
When I change my Legato project settings back to a Built-in Target Platform, debugging works fine again.
The debugging process always stops at the command below, because DS 5.3.1 gives 2 arguments to gdbCfg, which is not allowed. /legato/systems/current/bin/gdbCfg test test
Does somebody know which script is calling this command, or, is it embedded into DS ?
Mmm, I’m afraid that this behavior (coming from legacy gdbCfg interface) is implemented directly in DS code. The most strange thing is that it works with 18.03, since gdbCfg doesn’t look to have changed in 18.04 and later.
We’ll look into this ASAP, and see if we can provide a patch or a workaround.
So, after some investigation, it appears that DS is calling gdbCfg correctly, depending on the Legato version.
Actually, I can’t reproduce the situation where DS calls gdbCfg with process names when unexpected.
It is supposed to do it only when the detected Legato version running on the target is < 16.07, to fit with the legacy behavior.
But we have another problem; even if the sandbox is correctly configured, gdbserver refuses to be executed from it
Jan 7 17:29:59 | supervisor[32120]/supervisor T=main | proc.c proc_Start() 1366 | Could not exec ‘bin/gdbserver’. Permission denied.
While if we run gdbserver from the terminal, it is working OK.
Unfortunately, the promised patch for the end of this week won’t happen now that it has been identified as issue on the embedded side. We continue investigating to identify the root cause, but it will be a Legato patch rather than a DS one.
