From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16119 invoked by alias); 15 Aug 2014 04:40:31 -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 16064 invoked by uid 89); 15 Aug 2014 04:40:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f74.google.com Received: from mail-pa0-f74.google.com (HELO mail-pa0-f74.google.com) (209.85.220.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 15 Aug 2014 04:40:23 +0000 Received: by mail-pa0-f74.google.com with SMTP id lj1so571598pab.1 for ; Thu, 14 Aug 2014 21:40:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=8ZQ68Wjm+nWwbKpwWG/7zXpSz7JkI08nL9d1CwlHMXc=; b=GXPSC1rJ1ChxTNV1GrXstg40M4+trEEvUMIQ9PLRp9l30PrkEl5GWXoR+4yUFx2q6L sx5yNomDdRGhxCLXPxCIqjaroEE4cwQ2blgfbj9uU/M+/HHFFBkB8NpuR5MMJA3QU96z 9vZ6YeujzYEi9yJinRsMRjEz1UmJYiMPi6sgZ02d52AUr5tm348cVP/MZIW0gdlF5wnY Ku9/Gtg1hllBwqpSYfs6fLsMU9enQnVgj2qs9KFzuDYtdIlgI1ZlwS/JD2kiL1hAb8uj n3XIwermbtm8JLAuouDE5z0YYY8YOnf4bQfOyyf+wMAra8yBHhtiVzt4amQTRy23EETQ HUXQ== X-Gm-Message-State: ALoCoQkPRSR1R0u9ZOjAXQDy9x9f/3NFSiCqSrvEM8s5/l93paEl6IjJX5sIlA03658d8qF/gQW8 X-Received: by 10.70.90.47 with SMTP id bt15mr8212159pdb.4.1408077621876; Thu, 14 Aug 2014 21:40:21 -0700 (PDT) Received: from corp2gmr1-1.hot.corp.google.com (corp2gmr1-1.hot.corp.google.com [172.24.189.92]) by gmr-mx.google.com with ESMTPS id l23si518865yhg.1.2014.08.14.21.40.21 for (version=TLSv1.1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 14 Aug 2014 21:40:21 -0700 (PDT) Received: from ruffy.mtv.corp.google.com (ruffy.mtv.corp.google.com [172.17.128.44]) by corp2gmr1-1.hot.corp.google.com (Postfix) with ESMTP id 46CE031C31D; Thu, 14 Aug 2014 21:40:21 -0700 (PDT) From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21485.36660.648927.89507@ruffy.mtv.corp.google.com> Date: Fri, 15 Aug 2014 04:40:00 -0000 To: Yao Qi Cc: Subject: Re: [PATCH 2/2] Check function is GC'ed In-Reply-To: <1407307813-5321-2-git-send-email-yao@codesourcery.com> References: <53D8A264.1050103@codesourcery.com> <1407307813-5321-1-git-send-email-yao@codesourcery.com> <1407307813-5321-2-git-send-email-yao@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00268.txt.bz2 Yao Qi writes: > I see the following fail on arm-none-eabi target, > > (gdb) b 24^M > Breakpoint 1 at 0x4: file > ../../../../git/gdb/testsuite/gdb.base/break-on-linker-gcd-function.cc, > line 24.^M > (gdb) FAIL: gdb.base/break-on-linker-gcd-function.exp: b 24 > > Currently, we are using flag has_section_at_zero to determine whether > address zero in debug info means the corresponding code has been > GC'ed, like this: > > case DW_LNE_set_address: > address = read_address (abfd, line_ptr, cu, &bytes_read); > > if (address == 0 && !dwarf2_per_objfile->has_section_at_zero) > { > /* This line table is for a function which has been > GCd by the linker. Ignore it. PR gdb/12528 */ > > However, this is incorrect on some bare metal targets, as .text > section is located at 0x0. In this patch, we choose 'textlow' field > of partial symtabl. This patch fixes the fail above. It is > regression tested on x86_64-linux, arm-none-eabi, > arm-none-linux-gnueabi. OK to apply? Something in this explanation doesn't feel right. If .text is at zero then has_section_at_zero should be true. Perhaps the explanation just needs more elaboration, but looking at break-on-linker-gcd-function.exp the problem seems to be more that the test is invalid when .text begins at 0x0. If the testcase is invalid in this context (and we can discuss ways in which to cope with that), is there still a real bug here? > > gdb: > > 2014-08-06 Yao Qi > > * dwarf2read.c (dwarf_decode_lines_1): Skip the line table if > PST->textlow is greater than zero. > --- > gdb/dwarf2read.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c > index 8011e4e..5e292f2 100644 > --- a/gdb/dwarf2read.c > +++ b/gdb/dwarf2read.c > @@ -17229,6 +17229,8 @@ dwarf_decode_lines_1 (struct line_header *lh, const char *comp_dir, > /* Decode the table. */ > while (!end_sequence) > { > + struct partial_symtab *pst = NULL; > + > op_code = read_1_byte (abfd, line_ptr); > line_ptr += 1; > if (line_ptr > line_end) > @@ -17291,7 +17293,12 @@ dwarf_decode_lines_1 (struct line_header *lh, const char *comp_dir, > case DW_LNE_set_address: > address = read_address (abfd, line_ptr, cu, &bytes_read); > > - if (address == 0 && !dwarf2_per_objfile->has_section_at_zero) > + if (!decode_for_pst_p) > + pst = cu->per_cu->v.psymtab; I believe this is incorrect: .gdb_index may be in use and thus we're not using partial syms. > + > + if (address == 0 > + && (!dwarf2_per_objfile->has_section_at_zero > + || (pst != NULL && pst->textlow > address))) > { > /* This line table is for a function which has been > GCd by the linker. Ignore it. PR gdb/12528 */