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
Related
We have a ARM + DSP set up. Each has a specific invocation, the former uses the tmarm.exe and the latter uses the t32m6000.exe with the config.t32 file. What I want to know is, I have a cmm script that starts the ARM instance and then does a bunch of things and then it starts the DSP instance but after starting I don't know how to send commands to it. I am using the T32 lib via MATLAB so at one point I do a system('C6000start.bat') in MATLAB which issues the call to start the DSP and the DSP instance starts up but in the next line if I send any command to it it won't work. In the config6000.t32 file I have commented out the RCL, PORT and PACKLEN directives since t32m6000.exe flags a syntax error and I concluded that those directives only apply to the ARM.
I don't know if I have to use the INTERCOM command to switch focus to the DSP instance.
========== batch file C6000start.bat ===============
start "" %t32path%\t32m6000 -c config6000.t32
=====================================================
=============== config6000.t32=====================
; Environment variables
OS=
ID=T32
SYS=C:\T32
; USB information
PBI=
USB
; Printer settings
PRINTER=WINDOWS
; Remote Control Access
; Printer settings
PRINTER=WINDOWS
; Remote Control Access
;RCL=NETASSIST
;PORT=20001
;PACKLEN=1024
========================================================
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
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 write something into the dmesg log before /system being mounted.
my trouble is that for write into dmesg ( on android ) i need to use the android-specific stuff, not just my usually crossdev arm system.
just:
__android_log_print(ANDROID_LOG_DEBUG, "libnav", "DEBUG - custom program started");
all fine if you compile it as follow ( i make a standalone toolchain in /var/tmp/android ):
arm-linux-androideabi-gcc --sysroot /var/tmp/android/sysroot -llog -o custom_program custom_program.c
BUT the above command will build a dynamically linked executable, which will run fine if system is yet booted up.
"easy, just compile it statically!" i thought.
the android ndk comes with some libs but the liblog is only liblog.so, not liblog.a, so how can i log something in dmesg before /system beign mounted ?
thanks in advance.
Using arm-unknown-gnueabi-gcc and
fopen the /dev/kmsg and fprintf on the FILE * returned by fopen.
running the program while android is running will write into dmesg, but not if in early boot process. why?
#auselen
i yet have modified init to startup this static program:
init.rc snippet
on post-fs-data
write /dev/kmsg "launching test"
exec /data/test
all i see in dmesg is this...
<4>[ 6.336816] launching test
<6>[ 6.336902] init: command 'write' r=0
<6>[ 6.337115] init: command 'exec' r=-1
here you are the executable source code: http://pastebin.com/Hym1APWx
The run configuration works for a given set of arguments while the debug configuration fails.
This is my build configuration for ffmpeg.c
http://pastebin.com/PFM4K4xF
you can view from the build configuration generated . i have set posix style paths for the ffmpeg source.
the debug/run arguments are as -i Debug/sample2.mpg -ab 56k -ar 22050 -b 512k -r 30 -s 320x240 Debug/out2.flv
This all works fine when i run the program. The output file is generated.
But when i try to debug the ffmpeg.c program
it keeps stopping/hanging at certain instructions and the step over option disables.
like show_banner() and parse_options. ( when i commented out show_banner() it stoped at parse_options.)
more so in show_banner() -> cmdutils-> stops when trying to print swscale
and in parse_options->cmdutils.c-> stops at instruction po->u.func_arg(arg);
upon further inspection of stepping through i find this going into an infinite loop .
what is this error ? How do i resume stepping over instructions.
Has any one been able to debug completely from start to finish the ffmpeg.c after giving it valid input ? This is to observe the flow of execution based on the input's given.