From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22514 invoked by alias); 24 Jul 2006 21:39:59 -0000 Received: (qmail 22501 invoked by uid 22791); 24 Jul 2006 21:39:57 -0000 X-Spam-Check-By: sourceware.org Received: from smtp4-g19.free.fr (HELO smtp4-g19.free.fr) (212.27.42.30) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Jul 2006 21:39:55 +0000 Received: from [192.168.0.10] (pas38-3-82-229-199-15.fbx.proxad.net [82.229.199.15]) by smtp4-g19.free.fr (Postfix) with ESMTP id F176D33BDD; Mon, 24 Jul 2006 23:39:52 +0200 (CEST) Subject: Re: [PATCH] Allow dwarf2 debug info for function at address 0 From: =?ISO-8859-1?Q?Fr=E9d=E9ric?= Riss To: Daniel Jacobowitz Cc: Frederic RISS , gdb-patches@sources.redhat.com, Steven Johnson In-Reply-To: <20060724200457.GA15759@nevyn.them.org> References: <1153491793.7783.373.camel@crx549.cro.st.com> <20060724200457.GA15759@nevyn.them.org> Content-Type: multipart/mixed; boundary="=-JBMRqG1vBCzTp2BSJpJ9" Date: Mon, 24 Jul 2006 21:39:00 -0000 Message-Id: <1153777182.4946.26.camel@funkylaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-07/txt/msg00364.txt.bz2 --=-JBMRqG1vBCzTp2BSJpJ9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-length: 1303 Le lundi 24 juillet 2006 à 16:04 -0400, Daniel Jacobowitz a écrit : > On Fri, Jul 21, 2006 at 04:23:13PM +0200, Frederic RISS wrote: > > (BTW, > > was my testing defficient, or do recent GNU toolchains handle linkonce > > sections and associated debug info correctly?) > > It can be pretty hard to trigger this sort of problem. No, GNU > handling for linkonce debug info has not really changed in a while. OK; so my testing was deficient... but maybe we're not speaking of the same 'correct handling'? I thought that we had issues with relocating the debug information coming from different linkonce sections against the only one kept in the linked file... but that definitely works for me on a simple example. So I guess that we're referring to more deeply broken cases (for example when debug info is generated for a linkonce section of which all instances will get discarded). And I indeed have no idea how to generate such a case even by resorting to my more convoluted template-fu :-) > This patch is OK. > > One possible improvement; there's already a walk over all sections. > You could set this flag directly in dwarf2_locate_sections, I think. You're right, it's much nicer like this. I checked the attached in. (Oh, and thanks for fixing the date in my previous ChangeLog entry) --=-JBMRqG1vBCzTp2BSJpJ9 Content-Disposition: attachment; filename=dwarf2_use_vma.patch Content-Type: text/x-patch; name=dwarf2_use_vma.patch; charset=utf-8 Content-Transfer-Encoding: 7bit Content-length: 2409 2006-07-24 Frederic Riss * dwarf2read.c (struct dwarf2_per_objfile): Add has_section_at_zero field. (dwarf2_locate_sections): Initialize dwarf2_per_objfile->has_section_at_zero. (dwarf2_get_pc_bounds): Use dwarf2_per_objfile->has_section_at_zero instead of HAS_RELOC test. (read_partial_die): Ditto. Index: dwarf2read.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2read.c,v retrieving revision 1.200 diff -u -p -r1.200 dwarf2read.c --- dwarf2read.c 12 Jul 2006 21:14:57 -0000 1.200 +++ dwarf2read.c 24 Jul 2006 21:17:33 -0000 @@ -180,6 +180,10 @@ struct dwarf2_per_objfile /* A chain of compilation units that are currently read in, so that they can be freed later. */ struct dwarf2_per_cu_data *read_in_chain; + + /* A flag indicating wether this objfile has a section loaded at a + VMA of 0. */ + int has_section_at_zero; }; static struct dwarf2_per_objfile *dwarf2_per_objfile; @@ -1109,7 +1113,7 @@ dwarf2_has_info (struct objfile *objfile in. */ static void -dwarf2_locate_sections (bfd *ignore_abfd, asection *sectp, void *ignore_ptr) +dwarf2_locate_sections (bfd *abfd, asection *sectp, void *ignore_ptr) { if (strcmp (sectp->name, INFO_SECTION) == 0) { @@ -1170,6 +1174,10 @@ dwarf2_locate_sections (bfd *ignore_abfd dwarf2_per_objfile->ranges_size = bfd_get_section_size (sectp); dwarf_ranges_section = sectp; } + + if ((bfd_get_section_flags (abfd, sectp) & SEC_LOAD) + && bfd_section_vma (abfd, sectp) == 0) + dwarf2_per_objfile->has_section_at_zero = 1; } /* Build a partial symbol table. */ @@ -3177,7 +3185,7 @@ dwarf2_get_pc_bounds (struct die_info *d 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 && (bfd_get_file_flags (obfd) & HAS_RELOC) == 0) + if (low == 0 && !dwarf2_per_objfile->has_section_at_zero) return 0; *lowpc = low; @@ -5505,7 +5513,7 @@ read_partial_die (struct partial_die_inf if (has_low_pc_attr && has_high_pc_attr && part_die->lowpc < part_die->highpc && (part_die->lowpc != 0 - || (bfd_get_file_flags (abfd) & HAS_RELOC))) + || dwarf2_per_objfile->has_section_at_zero)) part_die->has_pc_info = 1; return info_ptr; } --=-JBMRqG1vBCzTp2BSJpJ9--