apportable debug give me attach error with - cocos2d-iphone

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.

Related

wsl2, gdb and cross-debug 32bit i386 - failing to map addresses to symbols ( in ?? () )

I'm having issues when trying to debug a cross compiled binary on my WSL2 host and only end up with backtraces with addresses in ?? (), any hint's on what to verify and change are welcome!
file mybin shows:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=..., with debug_info, not stripped
The application is started in WSL2 via qemu-i386(based on output from ps)
NOTE: I was wondering a bit about this because in my prev dev env using vm-ware and ubuntu 18.04 i was not seeing qemu-i386 used but did not think more about it based on WSL2 issues regarding 32bit application support referring to qemu and binfmt solving it.
I'm running gdb-multiarch (GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2)
Loading the executable and listing symbols with info functions <a_regex> works fine but when attaching and breaking i get bt's like this (NOTE output below is taken from VSCode with a few logging flags enabled, hence the -exec bt thing for example):
-exec bt
1: (777701) <-1183-interpreter-exec console "bt"
1: (777704) ->~"#0 0x000000000047a4ea in ?? ()\n"
1: (777707) ->~"#1 0x00007ffd2dcdb1c0 in ?? ()\n"
1: (777709) ->~"#2 0x0000000000467efc in ?? ()\n"
1: (777711) ->~"#3 0x0000000000000000 in ?? ()\n"
NOTE: When attaching i get the following warning:
warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64
setting architecture to i386:x86-64 is accepted by gdb but makes no difference
Setting a breakpoint gives the following error:
1: (40020) ->&"Cannot insert breakpoint 1.\n"
1: (40020) ->&"Cannot access memory at address 0xbce346f\n"
1: (40020) ->&"\n"
1: (40023) ->^error,msg="Command aborted."
UPDATE: SOLVED
Thought installing gcc-multilib solved it but it seems more likely the issue was because of a bug in Docker Desktop which has been fixed in v3.2.2. See description in my own answer below.
The qemu-i386 thing was bugging me so I decided to try compiling a simple .c with -m32 flag to check if it also would trigger being run via qemu, got errors because I was missing gcc-multilib so I installed it.
Started the buildt binary and noticed that it did not run via qemu-i386.
Started my original application again and this time it did also not start via qemu.
Started gdb-multiarch, loaded the bin and attached to the process and now suddenly everything worked fine, got a nice proper backtrace!

Automatic instrumentation with Score-P / Vampirtrace not working with gcc/g++

I have a simple helloworld.cpp to instrument with Score-P or Vampirtrace.
Installation of the performance/ tracing tools works fine. After compiling and running:
# score-p
scorep-g++ helloworld.cpp -o hello
export SCOREP_ENABLE_TRACING=true
export SCOREP_ENABLE_PROFILING=true
# vampirtrace
vtcxx -DVTRACE helloworld.cpp -o hello
# run
./hello
The created OTF files (OTF for vampirtrace/ OTF2 for Score-P) are more or less empty (no timeline data). I'm using Vampir to visualize the data.
More details:
I'm testing on Mac OS X (g++-8) and Xubuntu (g++-7; VirtualBox).
For Mac OS X I have installed brew install gcc.
For the instrumented Score-P version I also got a warning
[Score-P] src/measurement/profiling/scorep_profile_callpath.c:206: Warning: Master thread contains no regions.
but I can't find related issues/ help.
I also installed TAU and PDT for Vampirtrace, but nothing changed. By the way manual instrumentation works for Vampirtrace:
#include "vt_user.h"
...
VT_TRACER("name");
For Vampirtrace I also tested OpenMP instrumentation and this was working, but only that (no application tracing around).
For both environments I did not install Open MPI.
It would be great, if somebody has similar issues and could help.
PS: Later, I want to instrument an application with Poco::Threads. I only read about partial support for POSIX Threads.
Update
The problem is g++. I tried the same instrumentation with Intel icc and it worked.
The missing instrumentation with g++ is also possible with icc, if you add the parameter --nocompiler like
score-p --nocompiler icc helloworld.cpp -o hello
Update
I had to install missing packages. There are logging outputs for ./configure with hints. One of the following package solved it:
apt-get install llvm libwrap0-dev libclang-dev gcc-7-plugin-dev

How to debug binaries from a MIPS firmware

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.

pyOCD, gdb instantly terminate in Eclipse

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?

How do you get nacl-gdb to show debug symbols when debugging?

I'm attempting to get the nacl-gdb working with one of the example applications provided with the nacl_sdk. In particular, I'm trying to get it working with the sample hello_tutorial application in the getting_started/part1 folder (the stub code from this tutorial: https://developers.google.com/native-client/dev/devguide/tutorial/tutorial-part1).
I've tried following the instructions here: https://developers.google.com/native-client/dev/devguide/devcycle/debugging#debugging-with-nacl-gdb
But whenever I connect to the target, gdb prints out the following:
(gdb) target remote localhost:4014
Remote debugging using localhost:4014
warning: Can not parse XML target description; XML support was disabled at compile time
0x00000000 in ?? ()
I can then continue and the application runs, but it it's very helpful without the debugging symbols. Anybody know why this might not be working properly?
I performed the following steps:
Modified the Makefile to build hello_tutorial.pexe without finalizing it, and added the -g flag when compiling, and re-ran make.
Ran pnacl-translate to create the .nexe files from the un-finalized .pexe.
../../toolchain/linux_pnacl/bin/pnacl-translate --allow-llvm-bitcode-input hello_tutorial.pexe -arch x86-64 -o hello_tutorial_x86_64.nexe
Modified the hello_tutorial.nmf to point to the nexe files instead of the pexe file.
Modified index.html to point to "application/x-nacl", instead of "application/x-pnacl"
Started Chrome with the following command:
/opt/google/chrome/chrome --enable-nacl --enable-nacl-debug --no-sandbox --disable-hang-monitor localhost:5103
Start up the debugger from the part1 folder with the following command:
../../toolchain/linux_x86_newlib/bin/x86_64-nacl-gdb
Ran the following commands from within gdb. (Note that it shows "no debugging symbols found" when reading from the nacl_irt_x86_64.nexe - is that a problem?)
(gdb) nacl-irt hello_tutorial_x86_64.nexe
Reading symbols from /home/bender/dev/nacl_sdk/pepper_33/getting_started/part1/hello_tutorial_x86_64.nexe...done.
(gdb) nacl-irt /opt/google/chrome/nacl_irt_x86_64.nexe
Reading symbols from /opt/google/chrome/nacl_irt_x86_64.nexe...(no debugging symbols found)...done.
(gdb) target remote localhost:4014
Remote debugging using localhost:4014
warning: Can not parse XML target description; XML support was disabled at compile time
0x00000000 in ?? ()
I'm running on Linux:
Linux bender-VirtualBox 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Looks like this is working okay if I use pepper_canary instead of pepper_33. Found some info at this link: https://code.google.com/p/nativeclient/issues/detail?id=3739