From patchwork Thu Dec 17 13:03:32 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 10044 Received: (qmail 124920 invoked by alias); 17 Dec 2015 13:03:56 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 123883 invoked by uid 89); 17 Dec 2015 13:03:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=collected, 4.1, cwd, dprintf X-HELO: mail-pf0-f181.google.com Received: from mail-pf0-f181.google.com (HELO mail-pf0-f181.google.com) (209.85.192.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 17 Dec 2015 13:03:44 +0000 Received: by mail-pf0-f181.google.com with SMTP id 68so30721150pfc.1 for ; Thu, 17 Dec 2015 05:03:44 -0800 (PST) X-Received: by 10.98.8.2 with SMTP id c2mr13799979pfd.19.1450357422961; Thu, 17 Dec 2015 05:03:42 -0800 (PST) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id 189sm11488055pfc.67.2015.12.17.05.03.40 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 17 Dec 2015 05:03:42 -0800 (PST) From: Yao Qi To: gdb-patches@sourceware.org Subject: find_and_open_source in symtab_to_fullname Date: Thu, 17 Dec 2015 13:03:32 +0000 Message-ID: <86egelns63.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Hi, I see the following unexpected behaviour of inserting breakpoints in gdb.base/dprint.exp, (gdb) dprintf 28,"arg=%d, g=%d\n", arg, g Dprintf 3 at 0x400afc: /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/dprintf.c:28. (2 locations) Two locations are created instead of one. 3 dprintf keep y printf "arg=%d, g=%d\n", arg, g^M 3.1 y 0x0000000000400afc in foo at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/dprintf.c:28^M 3.2 y 0x0000007fb7e34598 in __dprintf at dprintf.c:28 Breakpoint location 3.2 looks wired, and GDB can't generate target command for this location, so the following test fails. Two breakpoint locations are created even for normal breakpoint, see, (gdb) break 28 Breakpoint 4 at 0x400afc: /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/dprintf.c:28. (2 locations) 4 breakpoint keep y ^M 4.1 y 0x0000000000400afc in foo at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/dprintf.c:28^M 4.2 y 0x0000007fb7e34598 in __dprintf at dprintf.c:28 the dprintf.c (which has __dprintf) is from glibc, and my glibc build has debug information. <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_producer : (indirect string, offset: 0x6b): GNU C 4.9.2 20140904 (prerelease) -march=armv8-a -mlittle-endian -mabi=lp64 -g -O2 -std=gnu99 -fgnu89-inline -fmerge-all-constants -frounding-math -fPIC DW_AT_language : 1 (ANSI C) DW_AT_name : (indirect string, offset: 0xe27c): dprintf.c DW_AT_comp_dir : (indirect string, offset: 0xbbef): /cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/src/eglibc-linaro-2.19-2014.08/stdio-common Then I start to investigate how is the 2nd breakpoint location generated. When we type "break 28", GDB parses the linespec, and find the right address to insert breakpoint. According to linespec, https://sourceware.org/gdb/current/onlinedocs/gdb/Linespec-Locations.html "break 28" means insert the breakpoint on line 28 of current source file, which is XXX/gdb.base/dprintf.c. However, GDB will also collect all symtabs which matches XXX/gdb.base/dprintf.c (by collect_symtabs_from_filename), and during the iterations, dprintf.c from glibc is collected by mistake. GDB finds the full file name by symtab's filename field and SYMTAB_DIRNAME macro. In my case, symtab's filename is dprintf.c and SYMTAB_DIRNAME is /cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/src/eglibc-linaro-2.19-2014.08/stdio-common but find_and_open_source still finds dprintf.c in a list of directories, /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base:/cbuild/slaves/oorts/crosstool-ng/builds/aarch64-linux-gnu-linux/.build/src/eglibc-linaro-2.19-2014.08/stdio-common:$cwd so /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/dprintf.c exists and GDB thinks dprintf.c from glibc is found. I understand the problem but not sure what is the right fix. Any ideas? One idea is to not call collect_symtabs_from_filename if we know FULLNAME is an absolute path, like this below. Is it a minor performance optimization? diff --git a/gdb/linespec.c b/gdb/linespec.c index b2233b9..ab77e7e 100644 --- a/gdb/linespec.c +++ b/gdb/linespec.c @@ -1842,7 +1842,14 @@ create_sals_line_offset (struct linespec_state *self, fullname = symtab_to_fullname (self->default_symtab); VEC_pop (symtab_ptr, ls->file_symtabs); VEC_free (symtab_ptr, ls->file_symtabs); - ls->file_symtabs = collect_symtabs_from_filename (fullname); + + if (IS_ABSOLUTE_PATH (fullname)) + { + VEC_safe_push (symtab_ptr, ls->file_symtabs, self->default_symtab); + } + else + ls->file_symtabs = collect_symtabs_from_filename (fullname); + use_default = 1; }