I'm getting started with LLDB and am following the tutorial here: https://lldb.llvm.org/python_reference/lldb.SBDebugger-class.html. Whenever I Launch a target the process gets stuck in the launching state and will never launch. I've tried lldb in bash and it works perfectly. I've read through the documentation with the tutorial and can't find an explanation about the launching state, or how to discover what is causing it to get stuck.
System is Ubuntu 18.04 64 bit dual core 8GB RAM using python2.7.
The most simple code to reproduce the error is as follows:
import lldb
import os
exe = './a.out'
db = lldb.SBDebugger.Create()
db.SetAsync(False)
target = db.CreateTargetWithFileAndArch(exe, 'x86_64-linux-gnu')
pro = target.LaunchSimple(None,None,os.getcwd())
print(pro)
Running the python code will always give me the following output:
SBProcess: pid = 0, state = launching, threads = 0, executable = a.out
The a.out is just a heloworld.cpp compiled with clang++ -fstandalone-debug
UPDATE:
Thanks to Jim's suggestion I tried SBTarget.Launch() instead and used the error to discover that lldb could not find lldb-server-6.0.0 because it installs as lldb-server-6.0
The Fix
sudo ln -s /usr/bin/lldb-server6.0 /usr/bin/lldb-server6.0.0
Related
I have the newest (2020.3 EAP ATM) version of CLion and I currently use it to remote debug a program on an embedded target (linux-mipsel).
Everything works as expected, after a bit of configuration, using self-built cross-toolchain and gdbserver.
My only problem is hitting the "red square" to stop execution will neither kill the running program nor gdbserver itself.
This means next iteration of edit-compile-debug cycle I will have two copies of both (I can get more, if I insist) which will not work as each tries to open the same resources (e.g.: a serial port) concurrently.
I have to manually log into target and kill the offending processes.
Am I missing something, is it a known bug or what?
Small update:
gdbserver is actually killed (does not show in ps ax) but underlying program (debugee) is still there. I am unsure why I was convinced otherwise, my bad.
This is a known issue and will hopefully be fixed soon.
Here is the link to the youtrack issue: https://youtrack.jetbrains.com/issue/CPP-20346
You could try the suggested workarounds:
Add pre-deploy configuration which kills running instances of the program
Follow the instructions for the gdb configuration in the comments:
GDB Server: /bin/bash
GDB Server args: -c "gdbserver :1234 /home/pi/myapp; pkill -e myapp"
The second config did not work for me, so I added the execution of an external tool where I run in /bin/bash the command -c "pkill -e myapp || true". The true is mandatory to avoid errors if the program is not running.
I'm trying to exploit the binaries from Damn vulnerable Router Firmware but I have issues with debuggging with gdb.
to run the program i use this command :
sudo chroot . ./qemu-mipsel-static ./pwnable/Intro/stack_bof_01
and it works but when i try to run gdb with :
sudo chroot . ./qemu-mipsel-static gdb ./pwnable/Intro/stack_bof_01
I have that :
(gdb) r
Starting program: /pwnable/Intro/stack_bof_01
qemu: Unsupported syscall: 4026
Cannot exec /bin/bash: No such file or directory.
qemu: Unsupported syscall: 4026
Could not open /proc/12532/status
I tried to copy the binary in a qemu VM but I don't have the whole system so it don't work.
So , please , what's is the best way to debug a program from a firmware on a different architecture than x86 ?
In qemu user mode, run the program using the command with the option -g:
sudo chroot . ./qemu-mipsel-static -g 1234 ./pwnable/Intro/stack_bof_01
then start the gdb-multiarch (or gdb that corresponds to that architecture), and attach to it like this:
target remote 127.0.0.1:1234
then you can debug it happily.
TL;DR: A debug toolchain which works perfectly outside of Eclipse terminates automatically when started in Eclipse.
OS: macOS Sierra 10.12.3
IDE: Eclipse IDE for C/C++ Developers, Mars.2, Release 4.5.2
Target Board: WIZwiki-W7500P (via CMSIS-DAP for interactive debugging)
Embedded Platform: mbed-os 5.4
On-chip Debugger: pyOCD 0.8.1a1
Debugger: arm-none-eabi-gdb 7.12.0.20161204-git
Compiler: arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 6.2.1 20161205
Following this tutorial, my aim is to use gdb to debug in Eclipse. Via command line,
$ pyocd-gdbserver
successfully starts the server and detects the board, and
$ arm-none-eabi-gdb
successfully starts the debugger and can connect to the server. The program successfully compiles to binary via mbed-cli:
$ mbed compile -t GCC_ARM -m WIZWIKI_W7500P
and flashes to the board, and executes without issue.
In addition, an .elf is generated which can be interactively debugged, breakpoints can be added, and functions can be stepped-through while running on the board.
Finally, the program appears to export successfully to Eclipse:
$ mbed export -t eclipse_gcc_arm WIZWIKI_W7500P --profile mbed-os/tools/profiles/debug.json
including the automatic generation of a Makefile, which successfully orchestrates building in Eclipse.
However, in Eclipse both gdb and pyocd-gdbserver terminate shortly after beginning debug with the following output (despite being configured exactly as they are when I run them in my terminal):
gdb traces:
650,101 2-gdb-show language
650,102 2^done,value="auto"
650,102 (gdb)
650,103 3-data-evaluate-expression "sizeof (void*)"
650,104 3^done,value="4"
650,104 (gdb)
650,104 4-gdb-set language auto
pyocd-gdbserver (n.b. only the last line is different from what's seen in terminal):
WARNING:root:Unsupported board found 2203
INFO:root:DAP SWD MODE initialised
INFO:root:ROM table #0 # 0xe00ff000 cidr=b105100d pidr=4000bb471
INFO:root:[0]<e000e000:SCS-M0+ cidr=b105e00d, pidr=4000bb008, class=14>
INFO:root:[1]<e0001000:DWT-M0+ cidr=b105e00d, pidr=4000bb00a, class=14>
INFO:root:[2]<e0002000:BPU cidr=b105e00d, pidr=4000bb00b, class=14>
INFO:root:CPU core is Cortex-M0
INFO:root:4 hardware breakpoints, 0 literal comparators
INFO:root:2 hardware watchpoints
INFO:root:Telnet: server started on port 4444
INFO:root:GDB server started at port:3333
Started by GNU ARM Eclipse
Outcome:
I've reinstalled each component, begun a fresh workspace and experimented with preferences such as:
How do I prevent this debug system from terminating?
Environment: OS X 10.9, XCode 4.6.3,
tweejump git:(master) ✗ apportable --version
Apportable SDK version release_1.0.31 (53ea42fec9b094b91c988f3bfde6dff8ba683a4d starter)
clang version 7fc8b05e4f57f61dbbbe5c8e62581b0e0c42941e
gdb version ff0611b8b721b3bf393c655c7d147de52cc850ac
android sdk version r21.0.1.1
android ndk version r8d.1
unknown ninja
I downloaded tweetjump built it and install this game.
Then I want to check if I can debug with gdb using
apportable just_debug
and
ROOTED=yes apportable just_debug
all these two commands gave me same information;
building with TARGET_ARCH_ABI:armeabi ARM_NEON:False
Building to /Users/xxx/.apportable/SDK/Build/android-armeabi-debug
Loading configuration.
Finished parsing configuration.
scons: Building targets ...
Debugging...
Starting: Intent { cmp=com.iplayful.tweejump/com.apportable.activity.VerdeActivity (has extras) }
Warning: Activity not started, its current task has been brought to the front
Failed to load one the Breakpoints files:
/Users/xxx/workspace/tweejump/tweejump.xcodeproj/xcuserdata/xxx.xcuserdatad/xcdebugger/Breakpoints.xcbkptlist
/Users/xxx/workspace/tweejump/tweejump.xcodeproj/xcuserdata/xxx.xcuserdatad/xcdebugger/Breakpoints_v2.xcbkptlist
Attaching to pid 8085
Cannot attach to lwp 8085: Operation not permitted (1)
Exiting
I saw some run-as answer, but how can an android newbie work it out. Can I have a step by step tutorial.
Edit1:
device: SAMSUNG SCH-I739
Android version: 4.1.2
Edit2:
I searched and found a debug solution:
$ adb shell
$ su
$ cd /data/data/com.iplayful.tweejump/lib/gdbserver :1111 --attach 26337
in my Mac:
$ ~/.apportable/toolchain/macosx/gdb/bin/arm-elf-linux-gdb
(gdb) file ./gdb/app_process
(gdb) shell adb forward tcp:1111 tcp:1111
(gdb) target remote :1111
(gdb) continue
then, gdb attached to gdbserver.
But gdb can't find the symbol, so this is the second question.
If I use this method to debug game, where to find game's symbol and libraries?
It looks like there is a gdbserver running on the device in a bad state.
Try rebooting the device and then apportable just_debug
If there are still issues, add the Android device and Android version to the question.
I'm trying to run a Hello world C++ on Eclipse on Ubuntu 12.04. I installed g++ and wrote this code:
#include<vector>
#include<string>
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World" << endl;
return 0;
}
Compile output:
**** Build of configuration Debug for project TopCoder ****
make all
make: Nothing to be done for `all'.
**** Build Finished ****
Run output message:
Launching TopCoder has encountered a problem
Error starting process
Error starting process.
Exec_tty error:Cannot run program "/media/01CCE00FA6888D80/Achieve/Eclipse/TopCoder/Debug/TopCoder": Unknown reason
Exec_tty error:Cannot run program "/media/01CCE00FA6888D80/Achieve/Eclipse/TopCoder/Debug/TopCoder": Unknown reason
Exec_tty error:Cannot run program "/media/01CCE00FA6888D80/Achieve/Eclipse/TopCoder/Debug/TopCoder": Unknown reason
when I put the source code on ext4 drive it builds and run
I changed
proc /proc proc nodev,noexec,nosuid 0 0
in /etc/fstab to
proc /proc proc dev,exec,suid 0 0
But no usefulness.
You're tring to run an application from the /media/01CCE00FA6888D80 volume. Removable USB? The most likely culprit is noexec as an option to the default mount command line.
check if noexec is part of the options for mounting the filesystem using:
grep noexec /proc/mounts
if this results in output indicating that noexec is in effect for the file system then try:
sudo mount -o remount,exec /media/01CCE00FA6888D80
Also, if the removable volume is NTFS, your milage may vary.
Try to build it from the command line. Then you will know if the problem is involved with g++ or with eclipse. I guess you should change your compiler path somewhere in the eclipse, are you sure you have eclipse-cdt? THe easiest way to compile it is:
g++ yourfile.cpp
Your problem is that you're workspace is probably on a different drive than the one you installed ubuntu on
You are running you project over Linux . i had facing same issue when my project was in my E drive . i gave read -write permission but still that was not enough for me . The same error was keep coming when i was trying to run the project .
I have shifted my project in my Home folder ,gave permission and the project ran !! .
I believe there was a problem with some permission for LINUX C compiler .