Skip to content

Is anyone running our gdb-based Android debuginfo tests? #129139

Open

Description

@saethlin

This is mostly directed at @chriswailes, @maurer, and @mgeisler because you are the target maintainers for our Android targets.

I've been looking through our debuginfo tests, and I've found that a few of them were disabled years ago never revisited. Some of those tests are disabled only on Android. Based on the history linked from #10381, the last attempt to re-enable some of the mass-ignored android debuginfo tests was in 2015. So I'm not expecting any of you to really know the history here.

But currently (and I do not know for how long) we do not run any debuginfo tests on Android: https://github.com/rust-lang-ci/rust/actions/runs/10409799292/job/28830241725#step:25:23109

It seems like this is because compiletest looks for a gdb:

/// Returns (Path to GDB, GDB Version, GDB has Rust Support)
fn analyze_gdb(
gdb: Option<String>,
target: &str,
android_cross_path: &PathBuf,
) -> (Option<String>, Option<u32>, bool) {
#[cfg(not(windows))]
const GDB_FALLBACK: &str = "gdb";
#[cfg(windows)]
const GDB_FALLBACK: &str = "gdb.exe";
const MIN_GDB_WITH_RUST: u32 = 7011010;
let fallback_gdb = || {
if is_android_gdb_target(target) {
let mut gdb_path = match android_cross_path.to_str() {
Some(x) => x.to_owned(),
None => panic!("cannot find android cross path"),
};
gdb_path.push_str("/bin/gdb");
gdb_path
} else {
GDB_FALLBACK.to_owned()
}
};
let gdb = match gdb {
None => fallback_gdb(),
Some(ref s) if s.is_empty() => fallback_gdb(), // may be empty if configure found no gdb
Some(ref s) => s.to_owned(),
};
let mut version_line = None;
if let Ok(output) = Command::new(&gdb).arg("--version").output() {
if let Some(first_line) = String::from_utf8_lossy(&output.stdout).lines().next() {
version_line = Some(first_line.to_string());
}
}
let version = match version_line {
Some(line) => extract_gdb_version(&line),
None => return (None, None, false),
};
let gdb_native_rust = version.map_or(false, |v| v >= MIN_GDB_WITH_RUST);
(Some(gdb), version, gdb_native_rust)
}
but since compiletest doesn't find one, we skip the entire suite.

There is a fair amount of code in compiletest for handling debuginfo tests on Android. Since none of any of the code associated with running debuginfo tests on Android is currently being exercised, I suspect all of that code is just a time bomb for whoever eventually decides that we need those tests to be enabled.

In #128913 I am removing a number of ignore-test annotations from the test suite, and replacing them with more specific ignores where required. Because the entire suite is ignored for Android, I cannot do this.

So I have a few questions:

  • Is anyone running the debuginfo test suite on Android?
  • Would anyone object if I blindly remove all the other ignore-android annotations from the test suite?
  • Is anyone planning on working to re-enable the Android debuginfo tests? I've poked around, and it uses a bunch of Android SDK/emulator arcana that I do not understand. For example, I tried installing gdb-multiarch in the image, which results in the test suite managing to execute arm-linux-androideabi-gdb (which I cannot find in the container) but if I add set architecture to the gdb commands, the output is just i686/x86_64.
  • In my searching around for explanations about how to debug on Android, I found some mentions that one should be using lldb instead. Is that right?

Activity

  1. added
    A-testsuiteArea: The testsuite used to check the correctness of rustc
    O-androidOperating system: Android
    C-discussionCategory: Discussion or questions that doesn't represent real issues.
    on Aug 16, 2024
  2. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Aug 16, 2024
  3. removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Aug 16, 2024
  4. maurer commented on Aug 16, 2024

    @maurer
    Contributor

    I'm not currently working to re-enable these tests, and I don't expect to have time to do so soon.

    If someone wanted to do this, rather than installing gdb-multiarch, use either ndk-lldb or ndk-gdb which are installed as part of the NDK we're fetching. Those should:

    1. Have the right arch support
    2. Know how to connect to a process running in the emulator to debug it

    If someone was going to spend time getting one set of tests working, lldb would be massively preferred.

  5. mgeier commented on Aug 16, 2024

    @mgeier
    Contributor

    @saethlin I think you meant to tag someone else, I'm not a maintainer for any target.

  6. saethlin commented on Aug 16, 2024

    @saethlin
    MemberAuthor

    Right you are. Sorry about that.

  7. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    A-debuginfoArea: Debugging information in compiled programs (DWARF, PDB, etc.)
    on Aug 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-debuginfoArea: Debugging information in compiled programs (DWARF, PDB, etc.)A-testsuiteArea: The testsuite used to check the correctness of rustcC-discussionCategory: Discussion or questions that doesn't represent real issues.O-androidOperating system: AndroidT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions