lldb vs gdb in NDK23?

617 views
Skip to first unread message

John Dallman

unread,
Jun 7, 2022, 2:58:06 PM6/7/22
to andro...@googlegroups.com
Preface: I am not producing an Android app. I work for a software component business, creating shared libraries, compiled from C and C++ code, for use in third-party customers' apps. I test my libraries in a command-line test harness, which I run in the ADB shell. I am only producing software for 64-bit ARM, because none of the customers want 32-bit code. 

I gather lldb is now the debugger in Android Studio. However, I don't use Android Studio, and don't even install it. I find it far easier to do Android NDK work with editor and command line. I'm partially sighted, which is among the reasons for this. 

Looking at NDK23b on Linux, I see executables for both gdb and lldb and device-side servers for both. Could someone point me to documentation for getting lldb-server and lldb operating on an Android device connected by USB to my Linux development machine? 

Thanks,

John 

enh

unread,
Jun 7, 2022, 3:15:07 PM6/7/22
to android-ndk
On Tue, Jun 7, 2022 at 11:58 AM John Dallman <jgdats...@gmail.com> wrote:
Preface: I am not producing an Android app. I work for a software component business, creating shared libraries, compiled from C and C++ code, for use in third-party customers' apps. I test my libraries in a command-line test harness, which I run in the ADB shell. I am only producing software for 64-bit ARM, because none of the customers want 32-bit code. 

I gather lldb is now the debugger in Android Studio.

lldb was _always_ the debugger in Android Studio :-)

the change is that the supported command-line debugger is now lldb.
 
However, I don't use Android Studio, and don't even install it. I find it far easier to do Android NDK work with editor and command line. I'm partially sighted, which is among the reasons for this. 

Looking at NDK23b on Linux, I see executables for both gdb and lldb and device-side servers for both. Could someone point me to documentation for getting lldb-server and lldb operating on an Android device connected by USB to my Linux development machine? 

it should pretty much be "what you did with gdb/gdbserver, but replace gdb with lldb and gdbserver with lldbserver"... if you were already using the ndk-gdb script, it should just do the right thing behind the scenes for newer NDKs? on r23 you might have to use the --lldb argument to opt-in, if you're finding that that's landing you in gdb.

https://source.android.com/devices/tech/debug/gdb has links to the official lldb tutorial and "switcher's guide".
 
Thanks,

John 

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAH1xqgn8vfPbi16gdphXbJqL%3D4KSmpY9n3su9iF8z_w0vg%2B8VA%40mail.gmail.com.

John Dallman

unread,
Jun 8, 2022, 4:33:58 AM6/8/22
to andro...@googlegroups.com
Thanks, I'll have a go at this when I have an NDK23 build set up.

John

John Dallman

unread,
Jul 22, 2022, 10:40:39 AM7/22/22
to andro...@googlegroups.com
> it should pretty much be "what you did with gdb/gdbserver, but replace gdb with lldb 
> and gdbserver with lldbserver"... if you were already using the ndk-gdb script, it should 
> just do the right thing behind the scenes for newer NDKs? on r23 you might have to use 
> the --lldb argument to opt-in, if you're finding that that's landing you in gdb.

I wasn't. I have never used that script, and looking at it isn't telling me how to use it. Reminders: 

> I am not producing an Android app. I work for a software component business, creating 
> shared libraries, compiled from C and C++ code, for use in third-party customers' apps. 
> I test my libraries in a command-line test harness, which I run in the ADB shell.

> I don't use Android Studio, and don't even install it. I find it far easier to do Android NDK 
> work with editor and command line. I'm partially sighted, which is among the reasons for this. 

What I was doing with gdb and gdbserver was:

In one shell window, push the gdbserver executable to the same directory as my executable, then run this adb command:
adb forward tcp:12016 tcp:12016

In another 



On Tue, Jun 7, 2022 at 8:15 PM 'enh' via android-ndk <andro...@googlegroups.com> wrote:

John Dallman

unread,
Jul 22, 2022, 10:56:26 AM7/22/22
to andro...@googlegroups.com
> it should pretty much be "what you did with gdb/gdbserver, but replace gdb with lldb 
> and gdbserver with lldbserver"... if you were already using the ndk-gdb script, it should 
> just do the right thing behind the scenes for newer NDKs? on r23 you might have to use 
> the --lldb argument to opt-in, if you're finding that that's landing you in gdb.

I wasn't. I have never used that script, and looking at it isn't telling me how to use it. Reminders: 

> I am not producing an Android app. I work for a software component business, creating 
> shared libraries, compiled from C and C++ code, for use in third-party customers' apps. 
> I test my libraries in a command-line test harness, which I run in the ADB shell.

> I don't use Android Studio, and don't even install it. I find it far easier to do Android NDK 
> work with editor and command line. I'm partially sighted, which is among the reasons for this. 

What I was doing with gdb and gdbserver was:

In one shell window, push the gdbserver executable to the same directory as my executable, then run this adb command:
adb forward tcp:12016 tcp:12016

In another shell window, run the gdb client thus:

gdb -ex "target remote localhost:12016"

If I replace the gdb server with the lldb server, that window keeps saying:

Usage:
  ./lldb-server v[ersion]
  ./lldb-server g[dbserver] [options]
  ./lldb-server p[latform] [options]
Invoke subcommand for additional help

So it looks as if I need to run the lldb server on the device and give it localhost:12016 as an argument, followed by -- and the name of my test harness. 

I do not want to attach to a pid, because my test harness doesn't work that way. I need to be able to set breakpoints, tell the debugger to start the test harness, have it stop at my breakpoints, work in the debugger, and then let my test harness run to completion and exit. 

However, I can't see what arguments I need to give lldb.sh to tell it to talk to the device? They aren't much like the gdb arguments AFAICS.

The client I'm using is (NDK)/bin/lldb.sh and the server is (NDK)/ib64/clang/12.0.8/lib/linux/aarch64/lldb-server

Thanks, 

John

enh

unread,
Jul 22, 2022, 11:02:21 AM7/22/22
to android-ndk
i'd suggest you either use the ndk-gdb script to hide the details, or read it/run it once to see what the proper setup looks like and then adapt that to your environment.

John Dallman

unread,
Jul 22, 2022, 11:38:09 AM7/22/22
to andro...@googlegroups.com
> i'd suggest you either use the ndk-gdb script to hide the details, or read it/run it once to 
> see what the proper setup looks like and then adapt that to your environment.

I can't follow several of the instructions in https://developer.android.com/ndk/guides/ndk-gdb

For command-line native debugging to work, these requirements must be met:
  • Build your app using the ndk-build script. The ndk-gdb script does not support using the legacy make APP=<name> method to build.
I'm not using ndk-build. I have never used any of the Android Studio or NDK build systems, and have no idea how. 
  • Enable app debugging in your AndroidManifest.xml file by including an <application> element that sets the android:debuggable attribute to true.
I'm not building an app, and have no manifest. 
  • Use GNU Make 3.81 or higher.
I don't use any kind of make program. The software I work on doesn't use them at all. 
  • Build your app to run on Android 2.2 (Android API level 8) or higher.
  • Debug on a device or emulator running Android 2.2 or higher. For debugging purposes, the target API level that you declare in your AndroidManifest.xml file does not matter.
  • Develop your app in a Unix shell. On Windows, use Cygwin or the experimental ndk-gdb-py Python implementation.
Those are no problem: I'm building on Linux with API 28, and running on Android 9.0. 

If there's a way to get lldb to output the commands it runs, I could try to set up a conventional minimal app to get something for it to work on. I have never done this, because it simply isn't what my job needs, and it will be very hard for me if it involves GUI tools. I may have to settle for carrying on using GDB, as opposed to going through the basics of learning Android app programming, which is likely to take me a couple of weeks. 

Is there really no documentation for this? 

Thanks,

John


John Dallman

unread,
Jul 22, 2022, 11:45:15 AM7/22/22
to andro...@googlegroups.com
Another possibility: This page describes using gdbclient.py: https://source.android.com/devices/tech/debug/gdb

Is there a way to use that? Its example of debugging /system/bin/ls looks hopeful. However, there is no gdbclient.py in my NDK23. Where could I get it? 

Thanks, 

John

enh

unread,
Jul 22, 2022, 11:55:10 AM7/22/22
to android-ndk
On Fri, Jul 22, 2022 at 8:38 AM John Dallman <jgdats...@gmail.com> wrote:
> i'd suggest you either use the ndk-gdb script to hide the details, or read it/run it once to 
> see what the proper setup looks like and then adapt that to your environment.

I can't follow several of the instructions in https://developer.android.com/ndk/guides/ndk-gdb

For command-line native debugging to work, these requirements must be met:
  • Build your app using the ndk-build script. The ndk-gdb script does not support using the legacy make APP=<name> method to build.
I'm not using ndk-build. I have never used any of the Android Studio or NDK build systems, and have no idea how. 
  • Enable app debugging in your AndroidManifest.xml file by including an <application> element that sets the android:debuggable attribute to true.
I'm not building an app, and have no manifest. 
  • Use GNU Make 3.81 or higher.
I don't use any kind of make program. The software I work on doesn't use them at all. 
  • Build your app to run on Android 2.2 (Android API level 8) or higher.
  • Debug on a device or emulator running Android 2.2 or higher. For debugging purposes, the target API level that you declare in your AndroidManifest.xml file does not matter.
  • Develop your app in a Unix shell. On Windows, use Cygwin or the experimental ndk-gdb-py Python implementation.
Those are no problem: I'm building on Linux with API 28, and running on Android 9.0. 

If there's a way to get lldb to output the commands it runs, I could try to set up a conventional minimal app to get something for it to work on.

yeah, just build the "HelloJNI" sample in Studio and play along with that. (even if you _do_ have an app, that's often a better way to experiment, because it removes a ton of variables from the experiment.)
 
I have never done this, because it simply isn't what my job needs, and it will be very hard for me if it involves GUI tools. I may have to settle for carrying on using GDB, as opposed to going through the basics of learning Android app programming, which is likely to take me a couple of weeks. 

Is there really no documentation for this? 

for _apps_, no. "use Studio's GUI" is the best advice for the 99% of app developers, and the other 1% are assumed to already know how to set things up...

...but given that it sounds like you're actually closer to the "OS developer", you might find https://source.android.com/devices/tech/debug/gdb useful. (ignore the 'gdb', we're just preserving link stability and didn't think far enough ahead 10 years ago to call it something generic like "debugger"!) since you probably don't have an AOSP tree checked out, the script there is https://android.googlesource.com/platform/development/+/master/scripts/gdbclient.py (and you can click around in that UI to find the stuff it imports, or just git clone that individual git project and hack around with a copy of the scripts until they work outside the OS build environment).
 

Dan Albert

unread,
Jul 25, 2022, 2:46:46 PM7/25/22
to android-ndk
`ndk-gdb --help` does list some options that might help you attach to a non-app project. It's not something I've ever done that I can recall, but if none of those suit your needs, file a bug at https://github.com/android/ndk/issues? I can't promise that we'll be able to tackle it soon given the other tasks we have to balance, but aside from our available bandwidth I can't see any argument against supporting that kind of workflow. I imagine that does cover most middleware development workflows, since AGP support for native middleware distribution is still quite new (and is lacking some pretty important features still).

gdbclient is part of the platform, and afaik is only useful for debugging platform components: https://cs.android.com/android/platform/superproject/+/master:development/scripts/gdbclient.py. Between that and ndk-gdb you can probably work out the correct incantation for connecting LLDB to whatever you're working on (I've never worked on ndk-gdb and I don't think I've touched gdbclient for close to a decade, so you probably already know better than I do).

Another option (and this is the one I'd probably be trying myself, FWIW), is to set up an AGP project that can build your components as an AAR, add the tests as another gradle module, and then use Android Studio to debug the tests. I haven't actually tried debugging native tests in Android Studio before, but I don't think Studio even knows the difference between test code and app code, so it probably Just Works? If not, those are bugs worth chasing IMO.

If you want to try something that definitely isn't finished, but might be ready enough for some use cases, https://github.com/rr-debugger/rr is growing Android support atm and has some very cool features (replay/rewind).

enh

unread,
Jul 25, 2022, 2:55:41 PM7/25/22
to android-ndk
On Mon, Jul 25, 2022 at 11:46 AM 'Dan Albert' via android-ndk <andro...@googlegroups.com> wrote:
`ndk-gdb --help` does list some options that might help you attach to a non-app project. It's not something I've ever done that I can recall, but if none of those suit your needs, file a bug at https://github.com/android/ndk/issues? I can't promise that we'll be able to tackle it soon given the other tasks we have to balance, but aside from our available bandwidth I can't see any argument against supporting that kind of workflow. I imagine that does cover most middleware development workflows, since AGP support for native middleware distribution is still quite new (and is lacking some pretty important features still).

gdbclient is part of the platform, and afaik is only useful for debugging platform components: https://cs.android.com/android/platform/superproject/+/master:development/scripts/gdbclient.py.

no, you can use it for apps too.


though if your app isn't part of the platform (or something you don't have the source for), yeah, Studio >> ndk-gdb >> gdbclient.
 
Between that and ndk-gdb you can probably work out the correct incantation for connecting LLDB to whatever you're working on (I've never worked on ndk-gdb and I don't think I've touched gdbclient for close to a decade, so you probably already know better than I do).

Another option (and this is the one I'd probably be trying myself, FWIW), is to set up an AGP project that can build your components as an AAR, add the tests as another gradle module, and then use Android Studio to debug the tests. I haven't actually tried debugging native tests in Android Studio before, but I don't think Studio even knows the difference between test code and app code, so it probably Just Works? If not, those are bugs worth chasing IMO.

If you want to try something that definitely isn't finished, but might be ready enough for some use cases, https://github.com/rr-debugger/rr is growing Android support atm and has some very cool features (replay/rewind).

(but is going to be strictly harder to get set up than lldb. it has pretty much the same requirements from the device side, so you'll need to get through your current issue first anyway.)
 

John Dallman

unread,
Aug 15, 2022, 5:39:41 AM8/15/22
to andro...@googlegroups.com
Thanks for the help. I have not had a chance to work on this, having had Covid-19, and now some kind of post-Covid syndrome. For now, I'll have to use GDB, since it still works in NDK 23. 

John

Reply all
Reply to author
Forward
0 new messages