I'm trying to use lldb with openocd/jtag board but I'm in trouble.
I already use openocd with gdb to develop on L0 STMicroelectronics board and it works perfectly.
Now I want the same with lldb.
I do that on LLDB host side
$ lldb bin/token.elf
(lldb) target create "bin/token.elf"
Current executable set to 'bin/token.elf' (arm).
(lldb) platform select remote-gdb-server
Platform: remote-gdb-server
Connected: no
(lldb) platform connect connect://localhost:5557
Platform: remote-gdb-server
Hostname: (null)
Connected: yes
(lldb) target list
Current targets:
* target #0: /home/cme/Projects/Tacos/ledger/trunk/se/build/st31_bolos/bin/token.elf ( arch=arm-unknown-unknown, platform=host )
On the openocd/GDB server side I correctly see the "Info : accepting 'gdb' connection on tcp/5557"
But now I don't found how to continue:
(lldb) process launch
error: process launch failed: Child exec failed.
I also tried "process continue", but lldb complains there is no process
With gdb, the process is considered as already running and I use reset/continue commands, never the 'run' command.
Does anybody know how to use lldb with openocd/jtag gdb-server?
Thanks for your help
C/M.
from what we were researching, it is not possible to debug remote (bare-metal!) targets with lldb without writing extra code.
for basic functionality, lldb needs to recognize at least one thread context.
the same is true for gdb. But there in gdb there is some sort of stub implemented faking an existing thread on the remote system. [1]
from an conversation on the lldb mailing list [2] the answer compiles to:
we have to write some (python) code to get a remote bare metal working with lldb.
[1] https://github.com/bminor/binutils-gdb/blob/28170b88cc8b40fdea2b065dafe6e1872a47ee4e/gdb/remote.c#L1808
[2] http://comments.gmane.org/gmane.comp.debugging.lldb.devel/3405
So far this works for me on my stm32g0b1 nucleo board and pyOCD but I also tested with OpenOCD
$ lldb --local-lldbinit Build/temp.elf
(lldb) target create "Build/temp.elf"
Current executable set to '/home/diego/Workspace/genesis/Buil /temp.elf' (arm).
(lldb) gdb-remote 127.0.0.1:3333
Process 1 stopped
(lldb) target modules load --load .text 0x08000000
section '.text' loaded at 0x8000000
(lldb) process plugin packet monitor reset halt
packet: qRcmd,72657365742068616c74
response: 526573657474696e672074617267657420776974682068616c740a5375636365737366756c6c792068616c74656420646576696365206f6e2072657365740a
Related
I'm currently able to connect, load and debugg a Nucleo-G0B1 board with LLDB and pyOCD (also with OpenOCD) using the following sequence of commands:
$ lldb Build/temp.elf
(lldb) gdb-remote 127.0.0.1:3333
(lldb) target modules load --load .text 0x08000000
(lldb) process plugin packet monitor reset halt
But i'm not able to do the same thing with the LLDB python interface, currently
I'm trying to use the following mehods, prints for testing purposes
import lldb
debugger = lldb.SBDebugger.Create()
print(debugger.GetInstanceName())
error = lldb.SBError()
target = debugger.CreateTarget('Build/temp.elf', 'armv6m-*-none-eabi', 'remote-gdb-server', False, error)
print(error.GetCString())
print(target)
But so far no target is created. if I change the platform parameter to 'host' the target is created but I'm looking for a remote target not local
script output for remote-gdb-server
$ python lldbinit.py
debugger_1
platform 'remote-gdb-server' doesn't support 'armv6m-*-none-eabi'
No value
script output for host
$ python lldbinit.py
debugger_1
None
temp.elf
I am trying to debug my C code on CodeBlocks with GDB Debugger.
Unfortunately It does not work, I've tried almost everything including uninstall and re install CodeBlocks (debugger included).
Here's down below I'll put the exit error so you can get way better where the problem is:
Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
Release
Adding source dir: D:\20201105_es8_randomWalk\
Adding source dir: D:\20201105_es8_randomWalk\
Adding file: D:\20201105_es8_randomWalk\bin\Release\20201105_es8_randomWalk.exe
Changing directory to: D:/20201105_es8_randomWalk/.
Set variable: PATH=.;D:\programms\CodeBlocks\MinGW\bin;D:\programms\CodeBlocks\MinGW;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Users\pnmat\AppData\Local\Microsoft\WindowsApps
Starting debugger: D:\programms\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname -quiet -args D:/20201105_es8_randomWalk/bin/Release/20201105_es8_randomWalk.exe
done
Setting breakpoints
Reading symbols from D:/20201105_es8_randomWalk/bin/Release/20201105_es8_randomWalk.exe...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (GDB) 8.1
No symbol table is loaded. Use the "file" command.
Temporary breakpoint 3 ("D:/20201105_es8_randomWalk/main.c:23") pending.
Child process PID: 8516 [Inferior 1 (process 8516) exited normally]
Debugger finished with status 0
It seems like it does not hit any breakpoint I've inserted in the code.
I'm trying to use OpenOCD with GDB to debug the STM32F4 Cortex-M4 on my STM32F4Discovery board.
Setup:
Ubuntu 16.04
OpenOCD 0.9.0 (also tested with 0.10-dev)
arm-none-eabi-gdb 7.10
STM32F4Discovery with ST-Link v2 (V2J28S0)
Project code generated with STM32CubeMX
I made sure debug wire is enabled in STM32CubeMX (this keeps the debug wire pins in default state)
GCC flags are:
-mcpu=cortex-m4 -mthumb -mthumb-interwork -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections -g -fno-common -fmessage-length=0
I added simple blinking LED code to the main loop, to test the debugging.
I start OpenOCD with openocd -f board/stm32f4discovery.cfg -c "program build/discovery_simple_test.elf verify reset". OpenOCD flashes the chip and resets it. (Output of OpenOCD can be found here)
Now I connect to it with GDB:
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x08001450 in ?? ()
(gdb) set verbose on
(gdb) file "/abs_path/build/discovery_simple_test.elf"
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Load new symbol table from "/abs_path/build/discovery_simple_test.elf"? (y or n) y
Reading symbols from /abs_path/build/discovery_simple_test.elf...done.
Reading in symbols for /abs_path/Src/main.c...done.
(gdb) monitor reset
(gdb) break main
Breakpoint 1 at 0x8000232: file /abs_path/Src/main.c, line 71.
(gdb) break /abs_path/Src/main.c:93
Breakpoint 2 at 0x8000258: file /abs_path/Src/main.c, line 93.
The program should break at line 93, but it doesn't.
When I halt the execution and try to continue it, it doesn't continue:
(gdb) monitor halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x080006d8 msp: 0x2001ffe8
(gdb) monitor continue
//Program doesn't continue
What is going on and how can I fix it?
To fix this issue i add the following command in openocd :
-c gdb_breakpoint_override hard
May be another GDB-Instance is Running ?
"A program is being debugged already."
Look for a "arm-none-eabi-gdb" Process and kill it.
I guess the command to use is just continue and not monitor continue since you have to tell GDB that the underlying software is running.
monitor continue tells the embedded system to continue but GDB does not know about it (it does not interpret the meaning of the monitor command, openocd does).
I'm working on a patch for FFmpeg and need to debug my code. I'm loading an external library, and in order to test different library versions, I have them in different folders. To select which one I want to use, I've been using DYLD_LIBRARY_PATH=/path/to/lib/dir ./ffmpeg and that works okay. But when I try it within lldb, it crashes saying dyld: Library not loaded and Reason: image not found. This used to work pre-Xcode 7.1, but I just recently upgraded and it stopped working.
Here's my MVCE:
#include <stdio.h>
#include <stdlib.h>
int main() {
char* str = getenv("DYLD_LIBRARY_PATH");
if (str) puts(str);
else puts("(null)");
return 0;
}
Running this program as follows produces the output:
$ ./a.out
(null)
$ DYLD_LIBRARY_PATH=/tmp ./a.out
/tmp
That looks okay. But when I try to use lldb it fails:
$ DYLD_LIBRARY_PATH=/tmp lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) run
Process 54255 launched: './a.out' (x86_64)
(null)
Process 54255 exited with status = 0 (0x00000000)
Trying to set the environment variable inside lldb works:
lldb ./a.out
(lldb) target create "./a.out"
Current executable set to './a.out' (x86_64).
(lldb) env DYLD_LIBRARY_PATH=/tmp
(lldb) run
Process 54331 launched: './a.out' (x86_64)
/tmp
Process 54331 exited with status = 0 (0x00000000)
lldb version (it's from Xcode 7.1):
$ lldb --version
lldb-340.4.110
Question: Is this an intended new "feature," or is this a new bug in lldb (or am I totally crazy and this never used to work)? I'm quite positive lldb used to forward the DYLD_LIBRARY_PATH environment variable, so how come it isn't anymore?
Edit: This is on OS X 10.11.1.
If this is on El Capitan (OS X 10.11), then it's almost certainly a side effect of System Integrity Protection. From the System Integrity Protection Guide: Runtime Protections article:
When a process is started, the kernel checks to see whether the main
executable is protected on disk or is signed with an special system
entitlement. If either is true, then a flag is set to denote that it
is protected against modification. …
… Any dynamic linker (dyld)
environment variables, such as DYLD_LIBRARY_PATH, are purged when
launching protected processes.
Everything in /usr/bin is protected in this fashion. Therefore, when you invoke /usr/bin/lldb, all DYLD_* environment variables are purged.
It should work to run lldb from within Xcode.app or the Command Line Tools, like so:
DYLD_LIBRARY_PATH=whatever /Applications/Xcode.app/Contents/Developer/usr/bin/lldb <whatever else>
I don't believe that copy of lldb is protected. /usr/bin/lldb is actually just a trampoline that executes the version in Xcode or the Command Line Tools, so you're ultimately running the same thing. But /usr/bin/lldb is protected so the DYLD_* environment variables are purged when running that.
Otherwise, you will have to set the environment variable inside lldb as shown in this thread:
(lldb) process launch --environment DYLD_LIBRARY_PATH=<mydylibpath> -- arg1 arg2 arg3
or using the short -v option:
(lldb) process launch -v DYLD_LIBRARY_PATH=<mydylibpath> -- arg1 arg2 arg3
Or, you can disable System Integrity Protection, although it serves a good purpose.
You can set an environment variable inside lldb once it is started.
$ lldb
(lldb) help env
Shorthand for viewing and setting environment variables. Expects 'raw' input (see 'help raw-input'.)
Syntax:
_regexp-env // Show environment
_regexp-env <name>=<value> // Set an environment variable
'env' is an abbreviation for '_regexp-env'
(lldb)
So that
lldb ./a.out
(lldb) env DYLD_LIBRARY_PATH=/path/to/lib/dir
(lldb) r
should work.
Tested with
$ lldb --version
lldb-1400.0.38.17
Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)
i'm trying to debug a C program, which runs on an ARM926EJ-S rev 5 (v5l). The software was cross-compiled (and is statically linked) with the std. arm-linux-gnueabi compiler (intalled via synaptic). I run Ubuntu 13.04 64bit. On the device is a Busybox v1.18.2. I successfully compiled gdbserver (with host=arm-linux-gnueabi) and gdb (with target=arm-linux-gnueabi) and can start my program on the embedded device via the locally running gdb...
My problem now is, that i don't have a proper backtrace output.
Message of gdb:
Remote debugging using 192.168.21.127:2345
0x0000a79c in ?? ()
(gdb) run
The "remote" target does not support "run". Try "help target" or "continue".
(gdb) continue
Continuing.
Cannot access memory at address 0x0
Program received signal SIGINT, Interrupt.
0x00026628 in ?? ()
(gdb) backtrace
#0 0x00026628 in ?? ()
#1 0x00036204 in ?? ()
#2 0x00036204 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
I try to compile the software with -g, -g3 -gdwarf-2, -ggdb, -ggdb3 without any difference.
Has anybody an idea what i am missing here?
Is this a problem maybe with the BusyBox or do i need additional libs on my host system?
I also tried the function backtrace_symbols from execinfo.h with nearly the same output...
Thanks in advance for any reply.
Another way for debugging is use gdb inside board follow below steps.
1)Run gdb process and attach your process to gdb using attach <pid> command
2)Continue your process using c command in gdb
Whenever you find any SIGINT or SIGSEGV then refer stack of your process using bt command in gdb.