Recent commit
c1950dcc04c ("gdb/testsuite: fix failure from
gdb.python/py-corefile.exp") introduced proc expect_build_id_in_core_file,
which detects the problem that:
...
... some versions of the linker didn't place the build-id within the first
page of an ELF. As a result, the Linux kernel would not include the
build-id in the generated core file, ...
...
Use this proc in a few more test-cases, to deal with the same problem.
Tested on x86_64-linux, openSUSE Tumbleweed with ld 2.43.1.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/33528
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33528
return
}
+require {expect_build_id_in_core_file $binfile2}
+require {expect_build_id_in_core_file $library_filename}
+
if {![runto_main]} {
return
}
return
}
+require {expect_build_id_in_core_file $library_1_filename}
+require {expect_build_id_in_core_file $library_2_filename}
+require {expect_build_id_in_core_file $binfile}
+
# If the board file is automatically splitting the debug information
# into a separate file (e.g. the cc-with-gnu-debuglink.exp board) then
# this test isn't going to work.
check_loaded_debug false false
}
+# The following tests assume that the build-ids of binfile and libfile can be
+# found in the core file.
+require {expect_build_id_in_core_file $binfile}
+require {expect_build_id_in_core_file $libfile}
+
with_test_prefix "all objfiles available" {
# Another sanity check that GDB can find the files via the
# debug-file-directory.