From patchwork Tue Jun 2 13:38:03 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Taimoor Mirza X-Patchwork-Id: 7007 Received: (qmail 87971 invoked by alias); 2 Jun 2015 13:38:24 -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 87959 invoked by uid 89); 2 Jun 2015 13:38:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS, T_FROM_12LTRDOM autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Jun 2015 13:38:13 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YzmOP-0000Ow-Ri from Taimoor_Mirza@mentor.com for gdb-patches@sourceware.org; Tue, 02 Jun 2015 06:38:10 -0700 Received: from [137.202.157.84] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 2 Jun 2015 14:38:08 +0100 Message-ID: <556DB1BB.50601@codesourcery.com> Date: Tue, 2 Jun 2015 18:38:03 +0500 From: Taimoor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "gdb-patches@sourceware.org" Subject: Improving GDB's mechanism to check if function is GC'ed X-IsSubscribed: yes Hi, GDB currently uses following mechanism to check if function is GC'ed by the linker: For any function whose address is 0x0, if 'textlow' field of partial symbol table is not zero, function is considered to be GC'ed by the linker. Below is the code doing this: case DW_LNE_set_address: address = read_address (abfd, line_ptr, cu, &bytes_read); /* If address < lowpc then it's not a usable value, it's outside the pc range of the CU. However, we restrict the test to only address values of zero to preserve GDB's previous behaviour which is to handle the specific case of a function being GC'd by the linker. */ if (address == 0 && address < lowpc) { /* This line table is for a function which has been GCd by the linker. Ignore it. PR gdb/12528 */ This change was done in https://sourceware.org/ml/gdb-patches/2014-08/msg00468.html This does not work for cases where symbols are manually loaded using add-symbol-file command. For any incrementally loaded objfile whose symbols are added using add-symbol-file command can have function at 0x0 in debug info and can have its lowpc non-zero because of add-symbol-file command that allows user to provide section addresses. Current Problem =============== We are currently using GDB to debug Nucleus based bare-metal system that also allows to dynamically load and unload Nucleus process modules during system execution. We currently load symbols of a modules using add-symbol-file whenever a module is loaded at runtime. It is very common to have functions at address 0x0 in debug information and then lowpc in symbol table to be non-zero as it depends on section addresses given in add-symbol-file command. With above mentioned GC'ing mechanism, GDB assumes that all these functions are GC'ed by linker. Because of this breakpoints do not work properly in debug session. Possible Solution ================= * Modify GC checking mechanism to mark any function GC'ed using above mentioned mechanism only if objfile is not dynamically loaded. So, for any function with address 0x0, it'll be marked GC'ed only if lowpc is not zero and objfile is main symbol file. For this I have made following modifications in if condition: if (address == 0 && address < lowpc && (objfile->flags & OBJF_MAINLINE)) { I have regression tested this change and it seems to work fine. Only downside that it is possible (though not common) to load main symbol file using add-symbol-file command. In that case, GDB will not check for GC'ed functions. Attached is patch to better highlight this solution. I am open to any other suggestions to improve this GC'ing mechanism and solving this problem. Thanks, Taimoor diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c index f6b0c01..4f84b40 100644 --- a/gdb/dwarf2read.c +++ b/gdb/dwarf2read.c @@ -17665,7 +17665,8 @@ dwarf_decode_lines_1 (struct line_header *lh, struct dwarf2_cu *cu, the test to only address values of zero to preserve GDB's previous behaviour which is to handle the specific case of a function being GC'd by the linker. */ - if (address == 0 && address < lowpc) + if (address == 0 && address < lowpc + && (objfile->flags & OBJF_MAINLINE)) { /* This line table is for a function which has been GCd by the linker. Ignore it. PR gdb/12528 */