Trying to get LLDB working (Debugging in Android Studio) — Oculus
Welcome to the Oculus Developer Forums!

Your participation on the forum is subject to the Oculus Code of Conduct.

In general, please be respectful and kind. If you violate the Oculus Code of Conduct, your access to the developer forums may be revoked at the discretion of Oculus staff.

Trying to get LLDB working (Debugging in Android Studio)

8bit8bit Posts: 94 Oculus Start Member
edited November 2015 in Oculus Go Development
I'm trying to get debugging working in Android Studio for Native Applications.
I am able to get lldb connected and responding but cannot get a valid frame. After much googling I believe the reason for the invalid frames is because LLDB does not know how to read the registers correctly. If this is the case, it looks that this could be solved by loading a target definitions file into LLDB. Anyway, before going further I wanted to put this out there in case somebody else has run into this and has some suggestions.

My Setup:
Dev machine: Windows 8.1, Android Studio 1.4.1, ovr_sdk_mobile_1.0.0.0
Android Device: S6, Android 5.0.2
Connected via USB

My Steps:
1. Setup Android studio as explained here: https://developer.oculus.com/documentat ... droid-win/
2. Setup a Native debug project as explained here: https://developer.oculus.com/documentat ... dio-debug/
2a. Updated AndroidManifest.xml to use SDK version 21: <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="21" />
3. Click "Debug" to start (using VrCubeWorld_Framework-DEBUG).
-- I can see lldb-server is pushed to device
-- on device I can see lldb-server is running and mostly working
4. Click "Pause" in debugger twice. For some reason first click is ignored.
6. Go to "Debugger -> LLDB" window and I have a nice (lldb) prompt that works!
7. If I look at threads or "process status" I get this:
* thread #1: tid = 16327, name = 's.vrcubeworldfw', stop reason = signal SIGSTOP
frame #0: 0xffffffffffffffff
.. and a bunch of other threads like "mali-utility-wo" and "OVR::VrThread" ...
7a. Notice my frame is garbage: 0xffffffffffffffff
8. Googling around and looking at my logs leads me to believe that LLDB doesn't know how to read the registers correctly.
8a. Here is a post where they loaded a target definition file to resolve similar symptom: http://ddeville.me/2015/08/using-the-vm ... with-lldb/
8b. Here is an example of types of messages I see in my "gdb-server.log": "GDBRemoteCommunicationServerLLGS::SendStopReplyPacketForThread failed to get register info for register set 'General Purpose Registers', register index 0"

I'm not sure if this matters but I noticed that the lldb-server that gets uploaded to the device is an arm64-v8a binary while all of our code is armeabi-v7a binaries.

Maybe if I could get an armeabi-v7a target definitions file I could make this work but thus far I have not been able to find one anywhere online.

If you have debugging working or have suggestions I would appreciate them. Thanks.

I have attached my gdb-server.log for reference.

Comments

  • tsempletsemple Posts: 17
    NerveGear
    We've been using Visual Studio 2015 with its android development tools and have had lots of success source level debugging things.
  • dolesdoles Posts: 54 Oculus Staff
    The 64-bit lldb-server being pushed to your device is indeed the issue. This happens when native code is entirely built outside of Gradle on 64-bit devices. I know of two workarounds, 1) build some code in your project with Gradle (you can just build a dummy.cpp for armeabi-v7a to let it know you are 32-bit only), or 2) pretty hacky but you can backup the 64-bit version of lldb-server in your Android Studio install and replace it with the 32-bit one. Obviously #1 is preferable so you don't mess with your AS setup too much, but it may require switching to the experimental Android plugin for Gradle.
  • 8bit8bit Posts: 94 Oculus Start Member
    @tsemple - Thanks for the suggestion. So far building the Android Native and Standard projects in VS have been quite smooth but I still need to add the Oculus stuff in. Debugging worked out the box and it has a lot of nice explicitness for all of the compile/build options. I'm going to port the VrCubeWorld example to a clean VS 2015 project. If it goes well, I will post the process in a new topic and put the project on GitHub for others.

    @doles - Thank you for confirming the issue. I was considering doing option number 2 (replace lldb-server with 32bit) but realized that the IDE automagically pushes a new lldb-server every time you push the debug button. I can see the copying in the console but could not find where Android Studio does those calls - to hack it out. Anyway, I may try option 1 but for now I'm planning to go with Visual Studio because it just seems to work nicer. We shall see.
  • 8bit8bit Posts: 94 Oculus Start Member
    TLDR: Easy to make LLDB work but Android Studio IDE integration still didn't work. Anyway, I can wait for fix in next release.

    Ok I found a very simple but brutal way to fix lldb. Delete the "arm64-v8a" directory.
    For example on my system I deleted/moved this directory:
    C:\Program Files\Android\Android Studio\bin\lldb\android\arm64-v8a

    I figured this out by browsing the python files in the lldb directory. It automatically falls back to best debugger it can get. Anyway, even after this it still didn't have symbols loaded properly. It pulls from the "lib" version of my built files instead of the "obj" version (which has symbols). I manually loaded symbols in lldb using
    tar mod add D:/dev/ovr_sdk_mobile_1.0.0.0/VrSamples/Native/VrCubeWorld_Framework/Projects/Android/obj/local/armeabi-v7a/libvrcubeworld.so
    

    However, even after this it could not match my CPP breakpoints with the assembly in the libs. Also the floating point registers were never viewable ("reg read --all"). I could add breakpoints onto functions though using command line (e.g. br set -M VrCubeWorld::Frame) and step through the disassembly.

    Anyway, I know this stuff is still in a beta-type of state so I will wait for next release for this to be addressed. I hope this helps others.
Sign In or Register to comment.