From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28371 invoked by alias); 19 Aug 2016 14:02:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 28350 invoked by uid 89); 19 Aug 2016 14:02:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=PT_LOAD, lwp, pt_load, phdrs X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Aug 2016 14:02:47 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CD1743B3C2; Fri, 19 Aug 2016 14:02:45 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7JE2i2k016249; Fri, 19 Aug 2016 10:02:45 -0400 Subject: Re: warning: Could not load shared library symbols for linux-vdso.so.1. To: Yao Qi References: <86twercyuv.fsf@gmail.com> <89b5bdc8-0be2-538e-3932-1f5d4a1bc1e8@redhat.com> <86eg5ucmcv.fsf@gmail.com> <96141d5a-3384-8314-1274-d1348dafe0c5@redhat.com> <86twehaxl3.fsf@gmail.com> Cc: "gdb-patches@sourceware.org" From: Pedro Alves Message-ID: <99360558-784c-6bab-9d0c-86473a4f8b75@redhat.com> Date: Fri, 19 Aug 2016 14:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-08/txt/msg00202.txt.bz2 On 08/19/2016 12:40 PM, Yao Qi wrote: >> So below's the "ugly" patch. It's functionally exactly the same as >> the larger one. The switch to linux_so_ops was mainly "cosmetic". >> >> Let me know what you prefer. >> > > This patch is good to master and 7.12. Hmm, wait, wait, wait... I think we can do simpler and better even. If reading the elf out of core memory works, then that means that there must be a load segment that covers it. So that means we should be able to find a PT_LOAD segment for the vDSO, in the core file. E.g.,: $ readelf -l testsuite/outputs/gdb.base/vdso-warning/vdso-warning.core Elf file type is CORE (Core file) Entry point 0x0 There are 18 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align NOTE 0x0000000000000430 0x0000000000000000 0x0000000000000000 0x0000000000000c18 0x0000000000000000 R 1 ... LOAD 0x0000000000036048 0x00007ffff7ffa000 0x0000000000000000 0x0000000000002000 0x0000000000002000 R E 1 ... Hence the patch below. If this doesn't work, then I think the ones based on updating the vsyscall range from the memory bfd's size wouldn't either. And I think this one should work even for the cases that led to commit 5979d6b69b20 ("Handle VDSO section headers past end of page") too, thus making it even better. I even wrote ChangeLog entries this time... :-) WDYT? >From bdf1cb2aa3ef3b22fb80ce24c3b2d19ac5be9438 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Fri, 19 Aug 2016 14:09:06 +0100 Subject: [PATCH] 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-19 Pedro Alves * 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-19 Pedro Alves * gdb.base/vdso-warning.exp: Test core dumps too. Use with_test_prefix. Factor out bits to ... (test_no_vdso): ... this new procedure. --- gdb/linux-tdep.c | 35 ++++++++++++--- gdb/testsuite/gdb.base/vdso-warning.exp | 76 ++++++++++++++++++++++----------- 2 files changed, 82 insertions(+), 29 deletions(-) diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c index ab110b0..718dc1a 100644 --- a/gdb/linux-tdep.c +++ b/gdb/linux-tdep.c @@ -2287,17 +2287,42 @@ linux_vsyscall_range_raw (struct gdbarch *gdbarch, struct mem_range *range) long pid; char *data; - /* Can't access /proc if debugging a core file. */ - if (!target_has_execution) + if (target_auxv_search (¤t_target, AT_SYSINFO_EHDR, &range->start) <= 0) return 0; + /* It doesn't make sense to access the host's /proc when debugging a + core file. Instead, look for the PT_LOAD segment that matches + the vDSO. */ + if (!target_has_execution) + { + Elf_Internal_Phdr *phdrs; + long phdrs_size; + int num_phdrs, i; + + phdrs_size = bfd_get_elf_phdr_upper_bound (core_bfd); + if (phdrs_size == -1) + return 0; + + phdrs = (Elf_Internal_Phdr *) alloca (phdrs_size); + num_phdrs = bfd_get_elf_phdrs (core_bfd, phdrs); + if (num_phdrs == -1) + return 0; + + for (i = 0; i < num_phdrs; i++) + if (phdrs[i].p_type == PT_LOAD + && phdrs[i].p_vaddr == range->start) + { + range->length = phdrs[i].p_memsz; + return 1; + } + + return 0; + } + /* We need to know the real target PID to access /proc. */ if (current_inferior ()->fake_pid_p) return 0; - if (target_auxv_search (¤t_target, AT_SYSINFO_EHDR, &range->start) <= 0) - return 0; - pid = current_inferior ()->pid; /* Note that reading /proc/PID/task/PID/maps (1) is much faster than diff --git a/gdb/testsuite/gdb.base/vdso-warning.exp b/gdb/testsuite/gdb.base/vdso-warning.exp index af2b2b0..aeb85a2 100644 --- a/gdb/testsuite/gdb.base/vdso-warning.exp +++ b/gdb/testsuite/gdb.base/vdso-warning.exp @@ -13,42 +13,70 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see . +# 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. + standard_testfile if { [prepare_for_testing "failed to prepare" ${testfile} $srcfile] } { return -1 } -gdb_breakpoint "main" +with_test_prefix "setup" { + gdb_breakpoint "main" -# 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" + # 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" +} -gdb_run_cmd +proc test_no_vdso {command} { + global srcfile + global gdb_prompt -set test "stop without warning" -gdb_test_multiple "" $test { - -re "Could not load shared library symbols .*\r\n$gdb_prompt $" { - fail $test + 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 + } } - -re "\r\nBreakpoint \[0-9\]+, main .*\r\n$gdb_prompt $" { - pass $test + + # 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 + } } } -# 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 +# 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 } + + clean_restart ${testfile} + + test_no_vdso "core-file $corefile" } -- 2.5.5