From: Frederic RISS <frederic.riss@st.com>
To: gdb-patches@sources.redhat.com
Cc: Steven Johnson <sjohnson@sakuraindustries.com>
Subject: [PATCH] Allow dwarf2 debug info for function at address 0
Date: Fri, 21 Jul 2006 14:23:00 -0000 [thread overview]
Message-ID: <1153491793.7783.373.camel@crx549.cro.st.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]
Hi,
This is a follow-up to the "Problems with startup code symbols (Copious
warnings)" gdb@ thread found here:
http://sources.redhat.com/ml/gdb/2006-06/msg00051.html
The attached patch replaces the HAS_RELOC checks in dwarf2read.c with a
per-objfile lookup for a section loaded at 0. With this modification,
non-relocatable files that have a code at address 0 should be handled
better (no discarded debug information).
As Daniel pointed out in the referenced thread, this solution isn't
perfect because you can have valid code at 0 and at the same time
'orphaned' debug info that seemingly references the 0 address. However
in the long run tools should correctly handle things like .gnu.linkonce,
and with correct debug info this patch looks like the right thing. (BTW,
was my testing defficient, or do recent GNU toolchains handle linkonce
sections and associated debug info correctly?)
I regression tested this on native i686-pc-linux-gnu.
Steven, by re-reading the thread that initiated this proposal I'm not
sure that this will really change something for you because the subject
had a bit diverged from your particular problem. Nevertheless could you
still give it a try to see if it helps with your warning issue?
:ADDPATCH Dwarf2:
(Nice side-effect of the patch tracker: It reminded me that I needed to
actually attach the patch :-) )
Cheers,
Fred
[-- Attachment #2: dwarf2_use_vma.patch --]
[-- Type: text/x-patch, Size: 2704 bytes --]
2006-07-21 Frederic Riss <frederic.riss@st.com>
* dwarf2read.c (struct dwarf2_per_objfile): Add has_section_at_zero
field.
(dwarf2_has_info): 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 20 Jul 2006 16:24:42 -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;
@@ -1083,6 +1087,7 @@ int
dwarf2_has_info (struct objfile *objfile)
{
struct dwarf2_per_objfile *data;
+ asection *lower_sect = NULL;
/* Initialize per-objfile state. */
data = obstack_alloc (&objfile->objfile_obstack, sizeof (*data));
@@ -1090,6 +1095,10 @@ dwarf2_has_info (struct objfile *objfile
set_objfile_data (objfile, dwarf2_objfile_data_key, data);
dwarf2_per_objfile = data;
+ bfd_map_over_sections (objfile->obfd, find_lowest_section, &lower_sect);
+ if (lower_sect && bfd_section_vma (objfile->obfd, lower_sect) == 0)
+ data->has_section_at_zero = 1;
+
dwarf_info_section = 0;
dwarf_abbrev_section = 0;
dwarf_line_section = 0;
@@ -1099,7 +1108,7 @@ dwarf2_has_info (struct objfile *objfile
dwarf_eh_frame_section = 0;
dwarf_ranges_section = 0;
dwarf_loc_section = 0;
-
+
bfd_map_over_sections (objfile->obfd, dwarf2_locate_sections, NULL);
return (dwarf_info_section != NULL && dwarf_abbrev_section != NULL);
}
@@ -3177,7 +3186,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 +5514,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;
}
next reply other threads:[~2006-07-21 14:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-21 14:23 Frederic RISS [this message]
2006-07-24 20:05 ` Daniel Jacobowitz
2006-07-24 21:39 ` Frédéric Riss
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=1153491793.7783.373.camel@crx549.cro.st.com \
--to=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