Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@adacore.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tromey@adacore.com>
Subject: [PATCH RFC 0/6] Handle Android APK files
Date: Thu, 22 Oct 2026 12:28:10 -0600	[thread overview]
Message-ID: <20261022-android-apk-file-v1-0-8444bb5f832a@adacore.com> (raw)

While working on an Android port, we noticed that the Android
gdbserver could report a shared library coming from an APK, like

    /some/path/file.apk!/inner/path/libwhatever.so

This "!/" syntax presumably came from Java as the same thing was
typical there for referring to files inside of jars.

This series adds this capability.  I considered a few ways of doing
this, including writing a zip (an APK, like a jar, is really just a
zip file) reader.  In the end I thought it was better to rely on
Python, first because the zip reader there is already debugged, and
secondly because it doesn't involve any new dependencies (Python's zip
reader is part of the standard library).

I'm sending this first as an RFC.  Here I chose to extend the missing
objfile handler code to allow the scenario where a missing objfile
does not have a build-id.  This seemed like a straightforward
extension to me, but I thought it would be best to run this past
everyone before writing up the documentation and tests.

Another question is what to do with the Android handler.  I've
unconditionally enabled it here, because I don't think there's
currently a way for gdb to know it is targeting Android; but also
because TBH this seems reasaonbly safe, in the sense that nobody is
really going to name a file "/usr/lib/haha.apk!/youlose.so".  Still,
this is worth some discussion.

Finally, I wrote most of this before starting on the Python safety
API.  So, while this series uses the old-style approach, if this seems
generally acceptable, I'll update it after writing the tests.

Signed-off-by: Tom Tromey <tromey@adacore.com>
---
Tom Tromey (6):
      Add py-file.c
      Add py-iovec.c
      Allow missing build-id when finding an objfile
      Allow missing objfile handler to return a file
      Call ext_lang_find_objfile_from_buildid from solib_bfd_fopen
      Add gdb.handler.android module

 gdb/Makefile.in                        |   2 +
 gdb/build-id.c                         |   4 +-
 gdb/data-directory/Makefile.in         |   2 +
 gdb/extension.c                        |   2 +-
 gdb/extension.h                        |  21 +++
 gdb/python/lib/gdb/__init__.py         |  21 ++-
 gdb/python/lib/gdb/handler/__init__.py |  14 ++
 gdb/python/lib/gdb/handler/android.py  |  43 +++++
 gdb/python/lib/gdb/missing_objfile.py  |  28 ++++
 gdb/python/py-file.c                   | 298 +++++++++++++++++++++++++++++++++
 gdb/python/py-iovec.c                  | 130 ++++++++++++++
 gdb/python/python-internal.h           |   2 +
 gdb/python/python.c                    |  45 +++--
 gdb/solib.c                            |  18 +-
 gdb/symfile-debug.c                    |  20 ++-
 15 files changed, 617 insertions(+), 33 deletions(-)
---
base-commit: 638f6237867858a849f3d6ffa1a1f8d6cd669636
change-id: 20260521-android-apk-file-2fe1721342fc

Best regards,
--  
Tom Tromey <tromey@adacore.com>


             reply	other threads:[~2026-10-22 18:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-22 18:28 Tom Tromey [this message]
2026-10-22 18:28 ` [PATCH RFC 1/6] Add py-file.c Tom Tromey
2026-10-22 18:28 ` [PATCH RFC 2/6] Add py-iovec.c Tom Tromey
2026-10-22 18:28 ` [PATCH RFC 3/6] Allow missing build-id when finding an objfile Tom Tromey
2026-10-22 18:28 ` [PATCH RFC 4/6] Allow missing objfile handler to return a file Tom Tromey
2026-10-22 18:28 ` [PATCH RFC 5/6] Call ext_lang_find_objfile_from_buildid from solib_bfd_fopen Tom Tromey
2026-10-22 18:28 ` [PATCH RFC 6/6] Add gdb.handler.android module Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261022-android-apk-file-v1-0-8444bb5f832a@adacore.com \
    --to=tromey@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox