Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Frédéric Riss" <frederic.riss@gmail.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: Frederic RISS <frederic.riss@st.com>,
	gdb-patches@sources.redhat.com,
	 Steven Johnson <sjohnson@sakuraindustries.com>
Subject: Re: [PATCH] Allow dwarf2 debug info for function at address 0
Date: Mon, 24 Jul 2006 21:39:00 -0000	[thread overview]
Message-ID: <1153777182.4946.26.camel@funkylaptop> (raw)
In-Reply-To: <20060724200457.GA15759@nevyn.them.org>

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

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)

[-- Attachment #2: dwarf2_use_vma.patch --]
[-- Type: text/x-patch, Size: 2409 bytes --]

2006-07-24  Frederic Riss  <frederic.riss@st.com>

	* 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;
 }

  reply	other threads:[~2006-07-24 21:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-21 14:23 Frederic RISS
2006-07-24 20:05 ` Daniel Jacobowitz
2006-07-24 21:39   ` Frédéric Riss [this message]
2006-07-24 22:02     ` Daniel Jacobowitz
2006-07-24 22:30       ` Frédéric Riss

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1153777182.4946.26.camel@funkylaptop \
    --to=frederic.riss@gmail.com \
    --cc=drow@false.org \
    --cc=frederic.riss@st.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=sjohnson@sakuraindustries.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox