From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9589 invoked by alias); 22 Aug 2014 18:02:30 -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 9568 invoked by uid 89); 22 Aug 2014 18:02:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-oi0-f74.google.com Received: from mail-oi0-f74.google.com (HELO mail-oi0-f74.google.com) (209.85.218.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 22 Aug 2014 18:02:28 +0000 Received: by mail-oi0-f74.google.com with SMTP id a141so2216622oig.3 for ; Fri, 22 Aug 2014 11:02:26 -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=/165xU3b+jGlZMgbFssw+8dotD39rBtF3pmodMagh3E=; b=lPKgnt5kf1UEd9CDHPrpUPWWJSzuNix0IyHUWhI4UK8sa0uPYLZN2uu8PIiYLMXeJ3 rNmWJbh2bdpqyF/f7zzFIRtvYxkUseAn17DXFASUzDX8n6Yv3EF0Sv4XH+0q7EQOZwA8 W/3SZp6cvn5p1VbGSaA6mlI/ok+1ikfPKyylH6i9wdacdkrg5ilBP+epuTBAWN9vc65/ FMNVnOJ516LnL4pvdo6b2saini02SaxQ74ezBL8CgSSodp/j68SMTGqu9M9HQIAPBjb0 pLbTqAE8onxj3BGBu/N/FcGc4PiBL+++bvoeU8DnHtn9Xktk666OAlo2IXqvPdIgrQG2 2zUQ== X-Gm-Message-State: ALoCoQkcsjCejBklzKwQAry8EF9H+2DgNMhE9lg8NRc1Viesp5bxlx1jyweSBF+rEfy9zVDEkb7G X-Received: by 10.42.225.77 with SMTP id ir13mr5577329icb.3.1408730546138; Fri, 22 Aug 2014 11:02:26 -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 o69si1109246yhp.6.2014.08.22.11.02.26 for (version=TLSv1.1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Aug 2014 11:02:26 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com (ruffy2.mtv.corp.google.com [172.17.128.107]) by corp2gmr1-1.hot.corp.google.com (Postfix) with ESMTP id 9608331C145; Fri, 22 Aug 2014 11:02:25 -0700 (PDT) From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21495.34225.60705.175416@ruffy2.mtv.corp.google.com> Date: Fri, 22 Aug 2014 18:02:00 -0000 To: Yao Qi Cc: Subject: Re: [PATCH 2/3] Check data is GC'ed In-Reply-To: <1408609338-17561-2-git-send-email-yao@codesourcery.com> References: <53D8A264.1050103@codesourcery.com> <1408609338-17561-1-git-send-email-yao@codesourcery.com> <1408609338-17561-2-git-send-email-yao@codesourcery.com> X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00504.txt.bz2 Hi. Comments inline. Yao Qi writes: > We see the following fail on arm-none-eabi target, > > (gdb) print &var^M > $1 = (int *) 0x0 <_ftext>^M > (gdb) FAIL: gdb.dwarf2/dw2-var-zero-addr.exp: print &var > > Test dw2-var-zero-addr.exp is intended to test whether GDB can > correctly know variable var is GC'ed by linker. Currently, the > heuristic GDB is using is (see add_partial_symbol) > > && addr == 0 > && !dwarf2_per_objfile->has_section_at_zero > > however, it doesn't work for bare metal targets, on which certain > section is located at address zero. In this patch, we improve the > heuristic that if the variable address is zero, and section at address > zero is executable, we think the variable is GC'ed by linker, because > there can't be a variable in an executable section. In order to know > this, we replace flag has_section_at_zero with a pointer > section_at_zero. > > gdb: > > 2014-08-20 Yao Qi > > * dwarf2read.c (struct dwarf2_per_objfile) : > Remove. > : New field. Callers update. > (add_partial_symbol): Extend the condition to check whether the > section at zero is executable. > (new_symbol_full): Check whether the section at zero is > executable. > --- > gdb/dwarf2read.c | 32 +++++++++++++++++++------------- > 1 file changed, 19 insertions(+), 13 deletions(-) > > diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c > index cf2ce76..f5b6341 100644 > --- a/gdb/dwarf2read.c > +++ b/gdb/dwarf2read.c > @@ -278,9 +278,8 @@ struct dwarf2_per_objfile > original data was compressed using 'dwz -m'. */ > struct dwz_file *dwz_file; > > - /* A flag indicating wether this objfile has a section loaded at a > - VMA of 0. */ > - int has_section_at_zero; > + /* The section of this objfile loaded at a VMA of 0. */ > + asection *section_at_zero; If overlays are in use, could multiple sections be at zero? [I think so, but I haven't used overlays in awhile.] Storing a vector of sections_at_zero seems like massive overkill to solve this problem, maybe there's a simpler solution, I don't know. But I'm not opposed to it if it's the only solution we have at the moment. > > /* True if we are using the mapped index, > or we are faking it for OBJF_READNOW's sake. */ > @@ -2186,7 +2185,7 @@ dwarf2_locate_sections (bfd *abfd, asection *sectp, void *vnames) > > if ((bfd_get_section_flags (abfd, sectp) & SEC_LOAD) > && bfd_section_vma (abfd, sectp) == 0) > - dwarf2_per_objfile->has_section_at_zero = 1; > + dwarf2_per_objfile->section_at_zero = sectp; > } > > /* A helper function that decides whether a section is empty, > @@ -6851,7 +6850,13 @@ add_partial_symbol (struct partial_die_info *pdi, struct dwarf2_cu *cu) > > if (pdi->d.locdesc > && addr == 0 > - && !dwarf2_per_objfile->has_section_at_zero) > + /* When the address is 0, if the object file doesn't have > + section at zero or the section at zero is executable, > + we think address 0 means the corresponding variable is > + removed by linker, instead of there is a data at address > + 0. */ > + && (dwarf2_per_objfile->section_at_zero == NULL > + || dwarf2_per_objfile->section_at_zero->flags & SEC_CODE)) Could there be a DW_TAG_variable in SEC_CODE? Someone might put one there for a particular reason. > { > /* A global or static variable may also have been stripped > out by the linker if unused, in which case its address > @@ -7341,8 +7346,8 @@ dwarf2_read_symtab (struct partial_symtab *self, > = objfile_data (objfile->separate_debug_objfile_backlink, > dwarf2_objfile_data_key); > > - dwarf2_per_objfile->has_section_at_zero > - = dpo_backlink->has_section_at_zero; > + dwarf2_per_objfile->section_at_zero > + = dpo_backlink->section_at_zero; > } > > dwarf2_per_objfile->reading_partial_symbols = 0; > @@ -11758,7 +11763,7 @@ dwarf2_ranges_read (unsigned offset, CORE_ADDR *low_return, > /* A not-uncommon case of bad debug info. > Don't pollute the addrmap with bad data. */ > if (range_beginning + baseaddr == 0 > - && !dwarf2_per_objfile->has_section_at_zero) > + && !dwarf2_per_objfile->section_at_zero) Convention is to write "ptr == NULL" instead of "!ptr". > { > complaint (&symfile_complaints, > _(".debug_ranges entry has start address of zero" > @@ -11871,7 +11876,7 @@ dwarf2_get_pc_bounds (struct die_info *die, CORE_ADDR *lowpc, > labels are not in the output, so the relocs get a value of 0. > If this is a discarded function, mark the pc bounds as invalid, > so that GDB will ignore it. */ > - if (low == 0 && !dwarf2_per_objfile->has_section_at_zero) > + if (low == 0 && !dwarf2_per_objfile->section_at_zero) > return 0; > > *lowpc = low; > @@ -12095,7 +12100,7 @@ dwarf2_record_block_ranges (struct die_info *die, struct block *block, > > /* A not-uncommon case of bad debug info. > Don't pollute the addrmap with bad data. */ > - if (start == 0 && !dwarf2_per_objfile->has_section_at_zero) > + if (start == 0 && !dwarf2_per_objfile->section_at_zero) > { > complaint (&symfile_complaints, > _(".debug_ranges entry has start address of zero" > @@ -15668,7 +15673,7 @@ read_partial_die (const struct die_reader_specs *reader, > labels are not in the output, so the relocs get a value of 0. > If this is a discarded function, mark the pc bounds as invalid, > so that GDB will ignore it. */ > - if (part_die->lowpc == 0 && !dwarf2_per_objfile->has_section_at_zero) > + if (part_die->lowpc == 0 && !dwarf2_per_objfile->section_at_zero) > { > struct gdbarch *gdbarch = get_objfile_arch (objfile); > > @@ -17297,7 +17302,7 @@ dwarf_decode_lines_1 (struct line_header *lh, const char *comp_dir, > pst = cu->per_cu->v.psymtab; > > if (address == 0 > - && (!dwarf2_per_objfile->has_section_at_zero > + && (!dwarf2_per_objfile->section_at_zero > || (pst != NULL && pst->textlow > address))) > { > /* This line table is for a function which has been > @@ -17870,7 +17875,8 @@ new_symbol_full (struct die_info *die, struct type *type, struct dwarf2_cu *cu, > > if (SYMBOL_CLASS (sym) == LOC_STATIC > && SYMBOL_VALUE_ADDRESS (sym) == 0 > - && !dwarf2_per_objfile->has_section_at_zero) > + && (!dwarf2_per_objfile->section_at_zero > + || (dwarf2_per_objfile->section_at_zero->flags & SEC_CODE))) The SEC_CODE test doesn't feel right. I understand the intent, but someone might put a variable in .text for a reason. > { > /* When a static variable is eliminated by the linker, > the corresponding debug information is not stripped > -- > 1.9.3 >