binutils-gdb/gdb/testsuite/gdb.base/vdso-warning.exp

83 lines
2.4 KiB
Plaintext
Raw Normal View History

# Copyright 2012-2017 Free Software Foundation, Inc.
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1" With upstream glibc, GDB prints: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? A bug's been filed for glibc a few years back: http://sourceware.org/bugzilla/show_bug.cgi?id=13097 but it's still not resolved. It's not clear whether there's even consensus that this is indeed a glibc bug. It would actually be nice if GDB also listed the vDSO in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vDSO would be converted to load and relocate the vDSO's bfd behind the target_so_ops interface. - and then, once glibc links in the vDSO to its DSO list, we'd need to either: a) somehow hand over the vDSO from one target_so_ops to the other b) simply keep hiding glibc's entry. And then b) seems the simplest. With that in mind, this patch simply discards the vDSO from glibc's reported shared library list. We can match the vDSO address range with the addresses found iterating the dynamic linker list, to tell which dynamic linker entry is the vDSO. Tested on x86_64 Fedora 20. gdb/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * solib-svr4.c (svr4_read_so_list): Rename to ... (svr4_current_sos_1): ... this and change the function comment. (svr4_current_sos): New function. gdb/testsuite/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * gdb.base/vdso-warning.c: New file. * gdb.base/vdso-warning.exp: New file.
2014-10-10 16:57:13 +02:00
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
Fix PR gdb/20505 - Make vDSO detection work with core files Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-22 21:05:09 +02:00
# Test that on Linux, we don't warn about not finding the vDSO. E.g.:
#
# warning: Could not load shared library symbols for linux-vdso.so.1.
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1" With upstream glibc, GDB prints: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? A bug's been filed for glibc a few years back: http://sourceware.org/bugzilla/show_bug.cgi?id=13097 but it's still not resolved. It's not clear whether there's even consensus that this is indeed a glibc bug. It would actually be nice if GDB also listed the vDSO in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vDSO would be converted to load and relocate the vDSO's bfd behind the target_so_ops interface. - and then, once glibc links in the vDSO to its DSO list, we'd need to either: a) somehow hand over the vDSO from one target_so_ops to the other b) simply keep hiding glibc's entry. And then b) seems the simplest. With that in mind, this patch simply discards the vDSO from glibc's reported shared library list. We can match the vDSO address range with the addresses found iterating the dynamic linker list, to tell which dynamic linker entry is the vDSO. Tested on x86_64 Fedora 20. gdb/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * solib-svr4.c (svr4_read_so_list): Rename to ... (svr4_current_sos_1): ... this and change the function comment. (svr4_current_sos): New function. gdb/testsuite/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * gdb.base/vdso-warning.c: New file. * gdb.base/vdso-warning.exp: New file.
2014-10-10 16:57:13 +02:00
standard_testfile
if { [prepare_for_testing "failed to prepare" ${testfile} $srcfile] } {
return -1
}
Fix PR gdb/20505 - Make vDSO detection work with core files Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-22 21:05:09 +02:00
with_test_prefix "setup" {
gdb_breakpoint "main"
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1" With upstream glibc, GDB prints: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? A bug's been filed for glibc a few years back: http://sourceware.org/bugzilla/show_bug.cgi?id=13097 but it's still not resolved. It's not clear whether there's even consensus that this is indeed a glibc bug. It would actually be nice if GDB also listed the vDSO in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vDSO would be converted to load and relocate the vDSO's bfd behind the target_so_ops interface. - and then, once glibc links in the vDSO to its DSO list, we'd need to either: a) somehow hand over the vDSO from one target_so_ops to the other b) simply keep hiding glibc's entry. And then b) seems the simplest. With that in mind, this patch simply discards the vDSO from glibc's reported shared library list. We can match the vDSO address range with the addresses found iterating the dynamic linker list, to tell which dynamic linker entry is the vDSO. Tested on x86_64 Fedora 20. gdb/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * solib-svr4.c (svr4_read_so_list): Rename to ... (svr4_current_sos_1): ... this and change the function comment. (svr4_current_sos): New function. gdb/testsuite/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * gdb.base/vdso-warning.c: New file. * gdb.base/vdso-warning.exp: New file.
2014-10-10 16:57:13 +02:00
Fix PR gdb/20505 - Make vDSO detection work with core files Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-22 21:05:09 +02:00
# At least some versions of Fedora/RHEL glibc have local patches that
# hide the vDSO. This lines re-exposes it. See PR libc/13097,
# comment 2. There's no support for passing environment variables in
# the remote protocol, but that's OK -- if we're testing against a
# glibc that doesn't list the vDSO without this, the test should still
# pass.
gdb_test_no_output "set environment LD_DEBUG=unused"
}
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1" With upstream glibc, GDB prints: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? A bug's been filed for glibc a few years back: http://sourceware.org/bugzilla/show_bug.cgi?id=13097 but it's still not resolved. It's not clear whether there's even consensus that this is indeed a glibc bug. It would actually be nice if GDB also listed the vDSO in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vDSO would be converted to load and relocate the vDSO's bfd behind the target_so_ops interface. - and then, once glibc links in the vDSO to its DSO list, we'd need to either: a) somehow hand over the vDSO from one target_so_ops to the other b) simply keep hiding glibc's entry. And then b) seems the simplest. With that in mind, this patch simply discards the vDSO from glibc's reported shared library list. We can match the vDSO address range with the addresses found iterating the dynamic linker list, to tell which dynamic linker entry is the vDSO. Tested on x86_64 Fedora 20. gdb/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * solib-svr4.c (svr4_read_so_list): Rename to ... (svr4_current_sos_1): ... this and change the function comment. (svr4_current_sos): New function. gdb/testsuite/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * gdb.base/vdso-warning.c: New file. * gdb.base/vdso-warning.exp: New file.
2014-10-10 16:57:13 +02:00
Fix PR gdb/20505 - Make vDSO detection work with core files Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-22 21:05:09 +02:00
proc test_no_vdso {command} {
global srcfile
global gdb_prompt
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1" With upstream glibc, GDB prints: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? A bug's been filed for glibc a few years back: http://sourceware.org/bugzilla/show_bug.cgi?id=13097 but it's still not resolved. It's not clear whether there's even consensus that this is indeed a glibc bug. It would actually be nice if GDB also listed the vDSO in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vDSO would be converted to load and relocate the vDSO's bfd behind the target_so_ops interface. - and then, once glibc links in the vDSO to its DSO list, we'd need to either: a) somehow hand over the vDSO from one target_so_ops to the other b) simply keep hiding glibc's entry. And then b) seems the simplest. With that in mind, this patch simply discards the vDSO from glibc's reported shared library list. We can match the vDSO address range with the addresses found iterating the dynamic linker list, to tell which dynamic linker entry is the vDSO. Tested on x86_64 Fedora 20. gdb/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * solib-svr4.c (svr4_read_so_list): Rename to ... (svr4_current_sos_1): ... this and change the function comment. (svr4_current_sos): New function. gdb/testsuite/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * gdb.base/vdso-warning.c: New file. * gdb.base/vdso-warning.exp: New file.
2014-10-10 16:57:13 +02:00
Fix PR gdb/20505 - Make vDSO detection work with core files Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-22 21:05:09 +02:00
set message "startup"
gdb_test_multiple "$command" $message {
-re "Could not load shared library symbols .*\r\n$gdb_prompt $" {
fail $message
}
-re "main \\(\\) at .*$srcfile.*\r\n$gdb_prompt $" {
pass $message
}
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1" With upstream glibc, GDB prints: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? A bug's been filed for glibc a few years back: http://sourceware.org/bugzilla/show_bug.cgi?id=13097 but it's still not resolved. It's not clear whether there's even consensus that this is indeed a glibc bug. It would actually be nice if GDB also listed the vDSO in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vDSO would be converted to load and relocate the vDSO's bfd behind the target_so_ops interface. - and then, once glibc links in the vDSO to its DSO list, we'd need to either: a) somehow hand over the vDSO from one target_so_ops to the other b) simply keep hiding glibc's entry. And then b) seems the simplest. With that in mind, this patch simply discards the vDSO from glibc's reported shared library list. We can match the vDSO address range with the addresses found iterating the dynamic linker list, to tell which dynamic linker entry is the vDSO. Tested on x86_64 Fedora 20. gdb/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * solib-svr4.c (svr4_read_so_list): Rename to ... (svr4_current_sos_1): ... this and change the function comment. (svr4_current_sos): New function. gdb/testsuite/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * gdb.base/vdso-warning.c: New file. * gdb.base/vdso-warning.exp: New file.
2014-10-10 16:57:13 +02:00
}
Fix PR gdb/20505 - Make vDSO detection work with core files Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-22 21:05:09 +02:00
# Extra testing in case the warning changes and we miss updating
# the above.
set test "no vdso without symbols is listed"
gdb_test_multiple "info shared" $test {
-re "No\[^\r\n\]+linux-(vdso|gate).*$gdb_prompt $" {
fail $test
}
-re "$gdb_prompt $" {
pass $test
}
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1" With upstream glibc, GDB prints: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? A bug's been filed for glibc a few years back: http://sourceware.org/bugzilla/show_bug.cgi?id=13097 but it's still not resolved. It's not clear whether there's even consensus that this is indeed a glibc bug. It would actually be nice if GDB also listed the vDSO in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vDSO would be converted to load and relocate the vDSO's bfd behind the target_so_ops interface. - and then, once glibc links in the vDSO to its DSO list, we'd need to either: a) somehow hand over the vDSO from one target_so_ops to the other b) simply keep hiding glibc's entry. And then b) seems the simplest. With that in mind, this patch simply discards the vDSO from glibc's reported shared library list. We can match the vDSO address range with the addresses found iterating the dynamic linker list, to tell which dynamic linker entry is the vDSO. Tested on x86_64 Fedora 20. gdb/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * solib-svr4.c (svr4_read_so_list): Rename to ... (svr4_current_sos_1): ... this and change the function comment. (svr4_current_sos): New function. gdb/testsuite/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * gdb.base/vdso-warning.c: New file. * gdb.base/vdso-warning.exp: New file.
2014-10-10 16:57:13 +02:00
}
}
Fix PR gdb/20505 - Make vDSO detection work with core files Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-22 21:05:09 +02:00
# First, try a live process.
with_test_prefix "run" {
gdb_run_cmd
test_no_vdso ""
}
# Now, dump a core, and reload it.
with_test_prefix "core" {
set corefile [standard_output_file $testfile.core]
set core_supported [gdb_gcore_cmd "$corefile" "save a corefile"]
if {!$core_supported} {
return -1
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1" With upstream glibc, GDB prints: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? A bug's been filed for glibc a few years back: http://sourceware.org/bugzilla/show_bug.cgi?id=13097 but it's still not resolved. It's not clear whether there's even consensus that this is indeed a glibc bug. It would actually be nice if GDB also listed the vDSO in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vDSO would be converted to load and relocate the vDSO's bfd behind the target_so_ops interface. - and then, once glibc links in the vDSO to its DSO list, we'd need to either: a) somehow hand over the vDSO from one target_so_ops to the other b) simply keep hiding glibc's entry. And then b) seems the simplest. With that in mind, this patch simply discards the vDSO from glibc's reported shared library list. We can match the vDSO address range with the addresses found iterating the dynamic linker list, to tell which dynamic linker entry is the vDSO. Tested on x86_64 Fedora 20. gdb/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * solib-svr4.c (svr4_read_so_list): Rename to ... (svr4_current_sos_1): ... this and change the function comment. (svr4_current_sos): New function. gdb/testsuite/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * gdb.base/vdso-warning.c: New file. * gdb.base/vdso-warning.exp: New file.
2014-10-10 16:57:13 +02:00
}
Fix PR gdb/20505 - Make vDSO detection work with core files Loading a core dump that was either generated on a system running pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused set in the environment, solib-svr4.c:svr4_current_sos fails to filter out the vDSO, resulting in: (gdb) core-file corefile.core^M [New LWP 2362]^M warning: Could not load shared library symbols for linux-vdso.so.1.^M Do you need "set solib-search-path" or "set sysroot"?^M Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M ... The problem is that gdbarch_vsyscall_range does not support core inferiors at all. When live debugging, we're finding the vDSO's start address with auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the corresponding mapping, by parsing /proc/PID/maps. When debugging a core dump, we can also determine the starting address from auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core mappings out of the host's /proc. But we can instead look for a corresponding load segment in the core's bfd. gdb/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * linux-tdep.c (linux_vsyscall_range_raw): For core inferiors, find the vDSO's start address with AT_SYSINFO_EHDR too, and determine the vDSO's size by finding the PT_LOAD segment that matches AT_SYSINFO_EHDR. gdb/testsuite/ChangeLog: 2016-08-22 Pedro Alves <palves@redhat.com> PR gdb/20505 * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure.
2016-08-22 21:05:09 +02:00
clean_restart ${testfile}
test_no_vdso "core-file $corefile"
PR symtab/14466: Work around PR libc/13097 "linux-vdso.so.1" With upstream glibc, GDB prints: warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? A bug's been filed for glibc a few years back: http://sourceware.org/bugzilla/show_bug.cgi?id=13097 but it's still not resolved. It's not clear whether there's even consensus that this is indeed a glibc bug. It would actually be nice if GDB also listed the vDSO in the shared library list, but there are some design considerations with that: - the vDSO is mapped by the kernel, not userspace, therefore we should load its symbols right from the process's start of life, even before glibc / the userspace loader sets up the initial DSO list. The program might even be using a custom loader or no loader. - that kind of hints at that solib.c should handle retrieving shared library lists from more than one source, and that symfile-mem.c's loading of the vDSO would be converted to load and relocate the vDSO's bfd behind the target_so_ops interface. - and then, once glibc links in the vDSO to its DSO list, we'd need to either: a) somehow hand over the vDSO from one target_so_ops to the other b) simply keep hiding glibc's entry. And then b) seems the simplest. With that in mind, this patch simply discards the vDSO from glibc's reported shared library list. We can match the vDSO address range with the addresses found iterating the dynamic linker list, to tell which dynamic linker entry is the vDSO. Tested on x86_64 Fedora 20. gdb/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * solib-svr4.c (svr4_read_so_list): Rename to ... (svr4_current_sos_1): ... this and change the function comment. (svr4_current_sos): New function. gdb/testsuite/ 2014-10-10 Jan Kratochvil <jan.kratochvil@redhat.com> Pedro Alves <palves@redhat.com> PR symtab/14466 * gdb.base/vdso-warning.c: New file. * gdb.base/vdso-warning.exp: New file.
2014-10-10 16:57:13 +02:00
}