* [RFA] Work around binutils/15021
@ 2013-01-16 23:21 Doug Evans
2013-01-17 17:53 ` Tom Tromey
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Doug Evans @ 2013-01-16 23:21 UTC (permalink / raw)
To: gdb-patches, tromey; +Cc: ccoutant, saugustine
Hi.
I'd like to get this patch checked in, but I think it needs
another pair of eyes.
The core of the patch is really simple:
Split this union out:
union
{
/* The CUs we import using DW_TAG_imported_unit. This is filled in
while reading psymtabs, used to compute the psymtab dependencies,
and then cleared. Then it is filled in again while reading full
symbols, and only deleted when the objfile is destroyed. */
VEC (dwarf2_per_cu_ptr) *imported_symtabs;
/* Type units are grouped by their DW_AT_stmt_list entry so that they
can share them. If this is a TU, this points to the containing
symtab. */
struct type_unit_group *type_unit_group;
} s;
And then add this bit of code:
@@ -17584,6 +17600,16 @@ follow_die_sig (struct die_info *src_die
temp_die.offset.sect_off);
if (die)
{
+ /* For .gdb_index version 7 keep track of included TUs.
+ http://sourceware.org/bugzilla/show_bug.cgi?id=15021. */
+ if (dwarf2_per_objfile->index_table != NULL
+ && dwarf2_per_objfile->index_table->version <= 7)
+ {
+ VEC_safe_push (dwarf2_per_cu_ptr,
+ (*ref_cu)->per_cu->imported_symtabs,
+ sig_cu->per_cu);
+ }
+
*ref_cu = sig_cu;
return die;
}
The bulk of the patch is just handling splitting up the union.
Regression tested with gdb-generated .gdb_index version 7 (by hacking the
gdb-under-test to generate version 7), version 8, with dwz, and with gold.
2013-01-16 Doug Evans <dje@google.com>
Work around binutils/15021
* dwarf2read.c (dwarf2_per_cu_data): Split imported_symtabs and
type_unit_group out of union s. All uses updated.
(read_index_from_section): Watch for index version 8.
(follow_die_sig): If using .gdb_index version <= 7, record the TU as
an imported symtab.
(write_psymtabs_to_index): Increment version number to 8.
Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.728
diff -u -p -r1.728 dwarf2read.c
--- dwarf2read.c 14 Jan 2013 10:39:33 -0000 1.728
+++ dwarf2read.c 16 Jan 2013 22:00:11 -0000
@@ -566,19 +566,29 @@ struct dwarf2_per_cu_data
struct dwarf2_per_cu_quick_data *quick;
} v;
- union
- {
- /* The CUs we import using DW_TAG_imported_unit. This is filled in
- while reading psymtabs, used to compute the psymtab dependencies,
- and then cleared. Then it is filled in again while reading full
- symbols, and only deleted when the objfile is destroyed. */
- VEC (dwarf2_per_cu_ptr) *imported_symtabs;
-
- /* Type units are grouped by their DW_AT_stmt_list entry so that they
- can share them. If this is a TU, this points to the containing
- symtab. */
- struct type_unit_group *type_unit_group;
- } s;
+ /* The CUs we import using DW_TAG_imported_unit. This is filled in
+ while reading psymtabs, used to compute the psymtab dependencies,
+ and then cleared. Then it is filled in again while reading full
+ symbols, and only deleted when the objfile is destroyed.
+
+ This is also used to work around a difference between the way gold
+ generates .gdb_index version <=7 and the way gdb does. Arguably this
+ is a gold bug. For symbols coming from TUs, gold records in the index
+ the CU that includes the TU instead of the TU itself. This breaks
+ dw2_lookup_symbol: It assumes that if the index says symbol X lives
+ in CU/TU Y, then one need only expand Y and a subsequent lookup in Y
+ will find X. Alas TUs live in their own symtab, so after expanding CU Y
+ we need to look in TU Z to find X. Fortunately, this is akin to
+ DW_TAG_imported_unit, so we just use the same mechanism: For
+ .gdb_index version <=7 this also records the TUs that the CU referred
+ to. Concurrently with this change gdb was modified to emit version 8
+ indices so we only pay a price for gold generated indices. */
+ VEC (dwarf2_per_cu_ptr) *imported_symtabs;
+
+ /* Type units are grouped by their DW_AT_stmt_list entry so that they
+ can share them. If this is a TU, this points to the containing
+ symtab. */
+ struct type_unit_group *type_unit_group;
};
/* Entry in the signatured_types hash table. */
@@ -2690,9 +2700,14 @@ to use the section anyway."),
}
return 0;
}
+ /* Version 7 indices generated by gold refer to the CU for a symbol instead
+ of the TU (for symbols coming from TUs). It's just a performance bug, and
+ we can't distinguish gdb-generated indices from gold-generated ones, so
+ nothing to do here. */
+
/* Indexes with higher version than the one supported by GDB may be no
longer backward compatible. */
- if (version > 7)
+ if (version > 8)
return 0;
map->version = version;
@@ -2963,7 +2978,7 @@ dw2_get_file_names (struct objfile *objf
DWO file. */
if (this_cu->is_debug_types)
{
- struct type_unit_group *tu_group = this_cu->s.type_unit_group;
+ struct type_unit_group *tu_group = this_cu->type_unit_group;
init_cutu_and_read_dies (tu_group->t.first_tu, NULL, 0, 0,
dw2_get_file_names_reader, tu_group);
@@ -4981,10 +4996,10 @@ process_psymtab_comp_unit_reader (const
(objfile->static_psymbols.list + pst->statics_offset);
sort_pst_symbols (objfile, pst);
- if (!VEC_empty (dwarf2_per_cu_ptr, cu->per_cu->s.imported_symtabs))
+ if (!VEC_empty (dwarf2_per_cu_ptr, cu->per_cu->imported_symtabs))
{
int i;
- int len = VEC_length (dwarf2_per_cu_ptr, cu->per_cu->s.imported_symtabs);
+ int len = VEC_length (dwarf2_per_cu_ptr, cu->per_cu->imported_symtabs);
struct dwarf2_per_cu_data *iter;
/* Fill in 'dependencies' here; we fill in 'users' in a
@@ -4993,12 +5008,12 @@ process_psymtab_comp_unit_reader (const
pst->dependencies = obstack_alloc (&objfile->objfile_obstack,
len * sizeof (struct symtab *));
for (i = 0;
- VEC_iterate (dwarf2_per_cu_ptr, cu->per_cu->s.imported_symtabs,
+ VEC_iterate (dwarf2_per_cu_ptr, cu->per_cu->imported_symtabs,
i, iter);
++i)
pst->dependencies[i] = iter->v.psymtab;
- VEC_free (dwarf2_per_cu_ptr, cu->per_cu->s.imported_symtabs);
+ VEC_free (dwarf2_per_cu_ptr, cu->per_cu->imported_symtabs);
}
/* Get the list of files included in the current compilation unit,
@@ -5096,7 +5111,7 @@ create_type_unit_group (struct dwarf2_cu
per_cu = &tu_group->per_cu;
per_cu->objfile = objfile;
per_cu->is_debug_types = 1;
- per_cu->s.type_unit_group = tu_group;
+ per_cu->type_unit_group = tu_group;
if (dwarf2_per_objfile->using_index)
{
@@ -5433,7 +5448,7 @@ build_type_psymtab_dependencies (void **
++i)
{
pst->dependencies[i] = iter->v.psymtab;
- iter->s.type_unit_group = tu_group;
+ iter->type_unit_group = tu_group;
}
VEC_free (dwarf2_per_cu_ptr, tu_group->t.tus);
@@ -5754,7 +5769,7 @@ scan_partial_symbols (struct partial_die
process_psymtab_comp_unit (per_cu, 1);
VEC_safe_push (dwarf2_per_cu_ptr,
- cu->per_cu->s.imported_symtabs, per_cu);
+ cu->per_cu->imported_symtabs, per_cu);
}
break;
default:
@@ -6886,7 +6901,7 @@ recursively_compute_inclusions (VEC (dwa
VEC_safe_push (dwarf2_per_cu_ptr, *result, per_cu);
for (ix = 0;
- VEC_iterate (dwarf2_per_cu_ptr, per_cu->s.imported_symtabs, ix, iter);
+ VEC_iterate (dwarf2_per_cu_ptr, per_cu->imported_symtabs, ix, iter);
++ix)
recursively_compute_inclusions (result, all_children, iter);
}
@@ -6899,7 +6914,7 @@ compute_symtab_includes (struct dwarf2_p
{
gdb_assert (! per_cu->is_debug_types);
- if (!VEC_empty (dwarf2_per_cu_ptr, per_cu->s.imported_symtabs))
+ if (!VEC_empty (dwarf2_per_cu_ptr, per_cu->imported_symtabs))
{
int ix, len;
struct dwarf2_per_cu_data *iter;
@@ -6915,13 +6930,14 @@ compute_symtab_includes (struct dwarf2_p
NULL, xcalloc, xfree);
for (ix = 0;
- VEC_iterate (dwarf2_per_cu_ptr, per_cu->s.imported_symtabs,
+ VEC_iterate (dwarf2_per_cu_ptr, per_cu->imported_symtabs,
ix, iter);
++ix)
recursively_compute_inclusions (&result_children, all_children, iter);
- /* Now we have a transitive closure of all the included CUs, so
- we can convert it to a list of symtabs. */
+ /* Now we have a transitive closure of all the included CUs, and
+ for .gdb_index version 7 the included TUs, so we can convert it
+ to a list of symtabs. */
len = VEC_length (dwarf2_per_cu_ptr, result_children);
symtab->includes
= obstack_alloc (&dwarf2_per_objfile->objfile->objfile_obstack,
@@ -7004,7 +7020,7 @@ process_full_comp_unit (struct dwarf2_pe
static_block
= end_symtab_get_static_block (highpc + baseaddr, objfile, 0,
- per_cu->s.imported_symtabs != NULL);
+ per_cu->imported_symtabs != NULL);
/* If the comp unit has DW_AT_ranges, it may have discontiguous ranges.
Also, DW_AT_ranges may record ranges not belonging to any child DIEs
@@ -7100,10 +7116,10 @@ process_full_type_unit (struct dwarf2_pe
If this is the first TU to use this symtab, complete the construction
of it with end_expandable_symtab. Otherwise, complete the addition of
this TU's symbols to the existing symtab. */
- if (per_cu->s.type_unit_group->primary_symtab == NULL)
+ if (per_cu->type_unit_group->primary_symtab == NULL)
{
symtab = end_expandable_symtab (0, objfile, SECT_OFF_TEXT (objfile));
- per_cu->s.type_unit_group->primary_symtab = symtab;
+ per_cu->type_unit_group->primary_symtab = symtab;
if (symtab != NULL)
{
@@ -7118,8 +7134,8 @@ process_full_type_unit (struct dwarf2_pe
else
{
augment_type_symtab (objfile,
- per_cu->s.type_unit_group->primary_symtab);
- symtab = per_cu->s.type_unit_group->primary_symtab;
+ per_cu->type_unit_group->primary_symtab);
+ symtab = per_cu->type_unit_group->primary_symtab;
}
if (dwarf2_per_objfile->using_index)
@@ -7165,7 +7181,7 @@ process_imported_unit_die (struct die_in
if (maybe_queue_comp_unit (cu, per_cu, cu->language))
load_full_comp_unit (per_cu, cu->language);
- VEC_safe_push (dwarf2_per_cu_ptr, cu->per_cu->s.imported_symtabs,
+ VEC_safe_push (dwarf2_per_cu_ptr, cu->per_cu->imported_symtabs,
per_cu);
}
}
@@ -8054,9 +8070,9 @@ setup_type_unit_groups (struct die_info
/* If we're using .gdb_index (includes -readnow) then
per_cu->s.type_unit_group may not have been set up yet. */
- if (per_cu->s.type_unit_group == NULL)
- per_cu->s.type_unit_group = get_type_unit_group (cu, attr);
- tu_group = per_cu->s.type_unit_group;
+ if (per_cu->type_unit_group == NULL)
+ per_cu->type_unit_group = get_type_unit_group (cu, attr);
+ tu_group = per_cu->type_unit_group;
/* If we've already processed this stmt_list there's no real need to
do it again, we could fake it and just recreate the part we need
@@ -17584,6 +17600,16 @@ follow_die_sig (struct die_info *src_die
temp_die.offset.sect_off);
if (die)
{
+ /* For .gdb_index version 7 keep track of included TUs.
+ http://sourceware.org/bugzilla/show_bug.cgi?id=xyz. */
+ if (dwarf2_per_objfile->index_table != NULL
+ && dwarf2_per_objfile->index_table->version <= 7)
+ {
+ VEC_safe_push (dwarf2_per_cu_ptr,
+ (*ref_cu)->per_cu->imported_symtabs,
+ sig_cu->per_cu);
+ }
+
*ref_cu = sig_cu;
return die;
}
@@ -19634,7 +19660,7 @@ dwarf2_per_objfile_free (struct objfile
for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix)
VEC_free (dwarf2_per_cu_ptr,
- dwarf2_per_objfile->all_comp_units[ix]->s.imported_symtabs);
+ dwarf2_per_objfile->all_comp_units[ix]->imported_symtabs);
VEC_free (dwarf2_section_info_def, data->types);
@@ -20456,7 +20482,7 @@ write_psymtabs_to_index (struct objfile
total_len = size_of_contents;
/* The version number. */
- val = MAYBE_SWAP (7);
+ val = MAYBE_SWAP (8);
obstack_grow (&contents, &val, sizeof (val));
/* The offset of the CU list from the start of the file. */
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [RFA] Work around binutils/15021 2013-01-16 23:21 [RFA] Work around binutils/15021 Doug Evans @ 2013-01-17 17:53 ` Tom Tromey 2013-01-17 18:42 ` Doug Evans 2013-01-17 21:04 ` [RFA, doc RFA] " Doug Evans 2013-01-24 14:59 ` Regressions with dwz [Re: [RFA] Work around binutils/15021] Jan Kratochvil 2013-06-09 17:09 ` [RFA] Work around binutils/15021 Jan Kratochvil 2 siblings, 2 replies; 14+ messages in thread From: Tom Tromey @ 2013-01-17 17:53 UTC (permalink / raw) To: Doug Evans; +Cc: gdb-patches, ccoutant, saugustine >>>>> "Doug" == Doug Evans <dje@google.com> writes: Doug> Regression tested with gdb-generated .gdb_index version 7 (by hacking the Doug> gdb-under-test to generate version 7), version 8, with dwz, and with gold. I think index version bumps require a documentation update and also a binutils patch. Doug> Work around binutils/15021 IIUC, the version bump is part of the workaround for the gold bug, right? The idea being that gold will generate version 7 indices, causing gdb to take the "inclusion" path. (I'm just trying to make sure I understand what is going on.) Doug> + This is also used to work around a difference between the way gold Doug> + generates .gdb_index version <=7 and the way gdb does. Arguably this Doug> + is a gold bug. To me it doesn't seem arguable, but I'm curious to know what the case is for it not being a gold bug. Doug> @@ -19634,7 +19660,7 @@ dwarf2_per_objfile_free (struct objfile Doug> for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix) Doug> VEC_free (dwarf2_per_cu_ptr, Doug> - dwarf2_per_objfile->all_comp_units[ix]->s.imported_symtabs); Doug> + dwarf2_per_objfile->all_comp_units[ix]->imported_symtabs); If follow_die_sig can be called when one TU refers to another TU, then it seems like the TU could have a non-empty 'imported_symtabs', meaning that the loop here should also iterate over TUs. Tom ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFA] Work around binutils/15021 2013-01-17 17:53 ` Tom Tromey @ 2013-01-17 18:42 ` Doug Evans 2013-01-17 21:04 ` [RFA, doc RFA] " Doug Evans 1 sibling, 0 replies; 14+ messages in thread From: Doug Evans @ 2013-01-17 18:42 UTC (permalink / raw) To: Tom Tromey; +Cc: gdb-patches, Cary Coutant, Sterling Augustine On Thu, Jan 17, 2013 at 9:52 AM, Tom Tromey <tromey@redhat.com> wrote: >>>>>> "Doug" == Doug Evans <dje@google.com> writes: > > Doug> Regression tested with gdb-generated .gdb_index version 7 (by hacking the > Doug> gdb-under-test to generate version 7), version 8, with dwz, and with gold. > > I think index version bumps require a documentation update and also a > binutils patch. Blech. Must remember to type grep foo *.texinfo instead of *.texi. > Doug> Work around binutils/15021 > > IIUC, the version bump is part of the workaround for the gold bug, > right? The idea being that gold will generate version 7 indices, > causing gdb to take the "inclusion" path. (I'm just trying to make sure > I understand what is going on.) Yeah. In the end I may not be able to avoid always having to record the inclusions. But to handle an app with 10k CUs and 530k TUs I'd to know if I *can* avoid it before something goes into a spec that makes it really hard or impossible. > Doug> + This is also used to work around a difference between the way gold > Doug> + generates .gdb_index version <=7 and the way gdb does. Arguably this > Doug> + is a gold bug. > > To me it doesn't seem arguable, but I'm curious to know what the case is > for it not being a gold bug. I don't have a strong enough opinion on this. > Doug> @@ -19634,7 +19660,7 @@ dwarf2_per_objfile_free (struct objfile > > Doug> for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix) > Doug> VEC_free (dwarf2_per_cu_ptr, > Doug> - dwarf2_per_objfile->all_comp_units[ix]->s.imported_symtabs); > Doug> + dwarf2_per_objfile->all_comp_units[ix]->imported_symtabs); > > If follow_die_sig can be called when one TU refers to another TU, then > it seems like the TU could have a non-empty 'imported_symtabs', meaning > that the loop here should also iterate over TUs. Ah, righto. Revised patch to follow. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFA, doc RFA] Work around binutils/15021 2013-01-17 17:53 ` Tom Tromey 2013-01-17 18:42 ` Doug Evans @ 2013-01-17 21:04 ` Doug Evans 2013-01-18 7:17 ` Eli Zaretskii 2013-01-18 14:32 ` Tom Tromey 1 sibling, 2 replies; 14+ messages in thread From: Doug Evans @ 2013-01-17 21:04 UTC (permalink / raw) To: Tom Tromey, eliz; +Cc: gdb-patches, ccoutant, saugustine Tom Tromey writes: > >>>>> "Doug" == Doug Evans <dje@google.com> writes: > > Doug> Regression tested with gdb-generated .gdb_index version 7 (by hacking the > Doug> gdb-under-test to generate version 7), version 8, with dwz, and with gold. > > I think index version bumps require a documentation update and also a > binutils patch. > > Doug> Work around binutils/15021 > > IIUC, the version bump is part of the workaround for the gold bug, > right? The idea being that gold will generate version 7 indices, > causing gdb to take the "inclusion" path. (I'm just trying to make sure > I understand what is going on.) > > Doug> + This is also used to work around a difference between the way gold > Doug> + generates .gdb_index version <=7 and the way gdb does. Arguably this > Doug> + is a gold bug. > > To me it doesn't seem arguable, but I'm curious to know what the case is > for it not being a gold bug. > > Doug> @@ -19634,7 +19660,7 @@ dwarf2_per_objfile_free (struct objfile > > Doug> for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix) > Doug> VEC_free (dwarf2_per_cu_ptr, > Doug> - dwarf2_per_objfile->all_comp_units[ix]->s.imported_symtabs); > Doug> + dwarf2_per_objfile->all_comp_units[ix]->imported_symtabs); > > If follow_die_sig can be called when one TU refers to another TU, then > it seems like the TU could have a non-empty 'imported_symtabs', meaning > that the loop here should also iterate over TUs. How's this? Eli, this has a doc change. 2013-01-17 Doug Evans <dje@google.com> Work around binutils/15021 * dwarf2read.c (dwarf2_per_cu_data): Split imported_symtabs and type_unit_group out of union s. All uses updated. (read_index_from_section): Watch for index version 8. (follow_die_sig): If using .gdb_index version <= 7, record the TU as an imported symtab. (write_psymtabs_to_index): Increment version number to 8. doc/ * gdb.texinfo (Index Section Format): Document .gdb_index version 8. Index: dwarf2read.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2read.c,v retrieving revision 1.731 diff -u -p -r1.731 dwarf2read.c --- dwarf2read.c 15 Jan 2013 21:32:36 -0000 1.731 +++ dwarf2read.c 17 Jan 2013 20:57:32 -0000 @@ -566,19 +566,29 @@ struct dwarf2_per_cu_data struct dwarf2_per_cu_quick_data *quick; } v; - union - { - /* The CUs we import using DW_TAG_imported_unit. This is filled in - while reading psymtabs, used to compute the psymtab dependencies, - and then cleared. Then it is filled in again while reading full - symbols, and only deleted when the objfile is destroyed. */ - VEC (dwarf2_per_cu_ptr) *imported_symtabs; - - /* Type units are grouped by their DW_AT_stmt_list entry so that they - can share them. If this is a TU, this points to the containing - symtab. */ - struct type_unit_group *type_unit_group; - } s; + /* The CUs we import using DW_TAG_imported_unit. This is filled in + while reading psymtabs, used to compute the psymtab dependencies, + and then cleared. Then it is filled in again while reading full + symbols, and only deleted when the objfile is destroyed. + + This is also used to work around a difference between the way gold + generates .gdb_index version <=7 and the way gdb does. Arguably this + is a gold bug. For symbols coming from TUs, gold records in the index + the CU that includes the TU instead of the TU itself. This breaks + dw2_lookup_symbol: It assumes that if the index says symbol X lives + in CU/TU Y, then one need only expand Y and a subsequent lookup in Y + will find X. Alas TUs live in their own symtab, so after expanding CU Y + we need to look in TU Z to find X. Fortunately, this is akin to + DW_TAG_imported_unit, so we just use the same mechanism: For + .gdb_index version <=7 this also records the TUs that the CU referred + to. Concurrently with this change gdb was modified to emit version 8 + indices so we only pay a price for gold generated indices. */ + VEC (dwarf2_per_cu_ptr) *imported_symtabs; + + /* Type units are grouped by their DW_AT_stmt_list entry so that they + can share them. If this is a TU, this points to the containing + symtab. */ + struct type_unit_group *type_unit_group; }; /* Entry in the signatured_types hash table. */ @@ -2690,9 +2700,14 @@ to use the section anyway."), } return 0; } + /* Version 7 indices generated by gold refer to the CU for a symbol instead + of the TU (for symbols coming from TUs). It's just a performance bug, and + we can't distinguish gdb-generated indices from gold-generated ones, so + nothing to do here. */ + /* Indexes with higher version than the one supported by GDB may be no longer backward compatible. */ - if (version > 7) + if (version > 8) return 0; map->version = version; @@ -2963,7 +2978,7 @@ dw2_get_file_names (struct objfile *objf DWO file. */ if (this_cu->is_debug_types) { - struct type_unit_group *tu_group = this_cu->s.type_unit_group; + struct type_unit_group *tu_group = this_cu->type_unit_group; init_cutu_and_read_dies (tu_group->t.first_tu, NULL, 0, 0, dw2_get_file_names_reader, tu_group); @@ -4994,10 +5009,10 @@ process_psymtab_comp_unit_reader (const (objfile->static_psymbols.list + pst->statics_offset); sort_pst_symbols (objfile, pst); - if (!VEC_empty (dwarf2_per_cu_ptr, cu->per_cu->s.imported_symtabs)) + if (!VEC_empty (dwarf2_per_cu_ptr, cu->per_cu->imported_symtabs)) { int i; - int len = VEC_length (dwarf2_per_cu_ptr, cu->per_cu->s.imported_symtabs); + int len = VEC_length (dwarf2_per_cu_ptr, cu->per_cu->imported_symtabs); struct dwarf2_per_cu_data *iter; /* Fill in 'dependencies' here; we fill in 'users' in a @@ -5006,12 +5021,12 @@ process_psymtab_comp_unit_reader (const pst->dependencies = obstack_alloc (&objfile->objfile_obstack, len * sizeof (struct symtab *)); for (i = 0; - VEC_iterate (dwarf2_per_cu_ptr, cu->per_cu->s.imported_symtabs, + VEC_iterate (dwarf2_per_cu_ptr, cu->per_cu->imported_symtabs, i, iter); ++i) pst->dependencies[i] = iter->v.psymtab; - VEC_free (dwarf2_per_cu_ptr, cu->per_cu->s.imported_symtabs); + VEC_free (dwarf2_per_cu_ptr, cu->per_cu->imported_symtabs); } /* Get the list of files included in the current compilation unit, @@ -5109,7 +5124,7 @@ create_type_unit_group (struct dwarf2_cu per_cu = &tu_group->per_cu; per_cu->objfile = objfile; per_cu->is_debug_types = 1; - per_cu->s.type_unit_group = tu_group; + per_cu->type_unit_group = tu_group; if (dwarf2_per_objfile->using_index) { @@ -5446,7 +5461,7 @@ build_type_psymtab_dependencies (void ** ++i) { pst->dependencies[i] = iter->v.psymtab; - iter->s.type_unit_group = tu_group; + iter->type_unit_group = tu_group; } VEC_free (dwarf2_per_cu_ptr, tu_group->t.tus); @@ -5767,7 +5782,7 @@ scan_partial_symbols (struct partial_die process_psymtab_comp_unit (per_cu, 1); VEC_safe_push (dwarf2_per_cu_ptr, - cu->per_cu->s.imported_symtabs, per_cu); + cu->per_cu->imported_symtabs, per_cu); } break; default: @@ -6899,7 +6914,7 @@ recursively_compute_inclusions (VEC (dwa VEC_safe_push (dwarf2_per_cu_ptr, *result, per_cu); for (ix = 0; - VEC_iterate (dwarf2_per_cu_ptr, per_cu->s.imported_symtabs, ix, iter); + VEC_iterate (dwarf2_per_cu_ptr, per_cu->imported_symtabs, ix, iter); ++ix) recursively_compute_inclusions (result, all_children, iter); } @@ -6912,7 +6927,7 @@ compute_symtab_includes (struct dwarf2_p { gdb_assert (! per_cu->is_debug_types); - if (!VEC_empty (dwarf2_per_cu_ptr, per_cu->s.imported_symtabs)) + if (!VEC_empty (dwarf2_per_cu_ptr, per_cu->imported_symtabs)) { int ix, len; struct dwarf2_per_cu_data *iter; @@ -6928,13 +6943,14 @@ compute_symtab_includes (struct dwarf2_p NULL, xcalloc, xfree); for (ix = 0; - VEC_iterate (dwarf2_per_cu_ptr, per_cu->s.imported_symtabs, + VEC_iterate (dwarf2_per_cu_ptr, per_cu->imported_symtabs, ix, iter); ++ix) recursively_compute_inclusions (&result_children, all_children, iter); - /* Now we have a transitive closure of all the included CUs, so - we can convert it to a list of symtabs. */ + /* Now we have a transitive closure of all the included CUs, and + for .gdb_index version 7 the included TUs, so we can convert it + to a list of symtabs. */ len = VEC_length (dwarf2_per_cu_ptr, result_children); symtab->includes = obstack_alloc (&dwarf2_per_objfile->objfile->objfile_obstack, @@ -7017,7 +7033,7 @@ process_full_comp_unit (struct dwarf2_pe static_block = end_symtab_get_static_block (highpc + baseaddr, objfile, 0, - per_cu->s.imported_symtabs != NULL); + per_cu->imported_symtabs != NULL); /* If the comp unit has DW_AT_ranges, it may have discontiguous ranges. Also, DW_AT_ranges may record ranges not belonging to any child DIEs @@ -7113,10 +7129,10 @@ process_full_type_unit (struct dwarf2_pe If this is the first TU to use this symtab, complete the construction of it with end_expandable_symtab. Otherwise, complete the addition of this TU's symbols to the existing symtab. */ - if (per_cu->s.type_unit_group->primary_symtab == NULL) + if (per_cu->type_unit_group->primary_symtab == NULL) { symtab = end_expandable_symtab (0, objfile, SECT_OFF_TEXT (objfile)); - per_cu->s.type_unit_group->primary_symtab = symtab; + per_cu->type_unit_group->primary_symtab = symtab; if (symtab != NULL) { @@ -7131,8 +7147,8 @@ process_full_type_unit (struct dwarf2_pe else { augment_type_symtab (objfile, - per_cu->s.type_unit_group->primary_symtab); - symtab = per_cu->s.type_unit_group->primary_symtab; + per_cu->type_unit_group->primary_symtab); + symtab = per_cu->type_unit_group->primary_symtab; } if (dwarf2_per_objfile->using_index) @@ -7178,7 +7194,7 @@ process_imported_unit_die (struct die_in if (maybe_queue_comp_unit (cu, per_cu, cu->language)) load_full_comp_unit (per_cu, cu->language); - VEC_safe_push (dwarf2_per_cu_ptr, cu->per_cu->s.imported_symtabs, + VEC_safe_push (dwarf2_per_cu_ptr, cu->per_cu->imported_symtabs, per_cu); } } @@ -8067,9 +8083,9 @@ setup_type_unit_groups (struct die_info /* If we're using .gdb_index (includes -readnow) then per_cu->s.type_unit_group may not have been set up yet. */ - if (per_cu->s.type_unit_group == NULL) - per_cu->s.type_unit_group = get_type_unit_group (cu, attr); - tu_group = per_cu->s.type_unit_group; + if (per_cu->type_unit_group == NULL) + per_cu->type_unit_group = get_type_unit_group (cu, attr); + tu_group = per_cu->type_unit_group; /* If we've already processed this stmt_list there's no real need to do it again, we could fake it and just recreate the part we need @@ -17620,6 +17636,16 @@ follow_die_sig (struct die_info *src_die temp_die.offset.sect_off); if (die) { + /* For .gdb_index version 7 keep track of included TUs. + http://sourceware.org/bugzilla/show_bug.cgi?id=15021. */ + if (dwarf2_per_objfile->index_table != NULL + && dwarf2_per_objfile->index_table->version <= 7) + { + VEC_safe_push (dwarf2_per_cu_ptr, + (*ref_cu)->per_cu->imported_symtabs, + sig_cu->per_cu); + } + *ref_cu = sig_cu; return die; } @@ -19670,7 +19696,11 @@ dwarf2_per_objfile_free (struct objfile for (ix = 0; ix < dwarf2_per_objfile->n_comp_units; ++ix) VEC_free (dwarf2_per_cu_ptr, - dwarf2_per_objfile->all_comp_units[ix]->s.imported_symtabs); + dwarf2_per_objfile->all_comp_units[ix]->imported_symtabs); + + for (ix = 0; ix < dwarf2_per_objfile->n_type_units; ++ix) + VEC_free (dwarf2_per_cu_ptr, + dwarf2_per_objfile->all_type_units[ix]->per_cu.imported_symtabs); VEC_free (dwarf2_section_info_def, data->types); @@ -20492,7 +20522,7 @@ write_psymtabs_to_index (struct objfile total_len = size_of_contents; /* The version number. */ - val = MAYBE_SWAP (7); + val = MAYBE_SWAP (8); obstack_grow (&contents, &val, sizeof (val)); /* The offset of the CU list from the start of the file. */ Index: doc/gdb.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v retrieving revision 1.1042 diff -u -p -r1.1042 gdb.texinfo --- doc/gdb.texinfo 16 Jan 2013 17:31:39 -0000 1.1042 +++ doc/gdb.texinfo 17 Jan 2013 20:57:33 -0000 @@ -41031,12 +41031,18 @@ unless otherwise noted: @enumerate @item -The version number, currently 7. Versions 1, 2 and 3 are obsolete. +The version number, currently 8. Versions 1, 2 and 3 are obsolete. Version 4 uses a different hashing function from versions 5 and 6. Version 6 includes symbols for inlined functions, whereas versions 4 and 5 do not. Version 7 adds attributes to the CU indices in the -symbol table. @value{GDBN} will only read version 4, 5, or 6 indices +symbol table. Version 8 specifies that symbols from DWARF type units +(@samp{DW_TAG_type_unit}) refer to the type unit's symbol table and not the +compilation unit (@samp{DW_TAG_comp_unit}) using the type. + +@value{GDBN} will only read version 4, 5, or 6 indices by specifying @code{set use-deprecated-index-sections on}. +GDB has a workaround for potentially broken version 7 indices so it is +currently not flagged as deprecated. @item The offset, from the start of the file, of the CU list. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFA, doc RFA] Work around binutils/15021 2013-01-17 21:04 ` [RFA, doc RFA] " Doug Evans @ 2013-01-18 7:17 ` Eli Zaretskii 2013-01-18 14:32 ` Tom Tromey 1 sibling, 0 replies; 14+ messages in thread From: Eli Zaretskii @ 2013-01-18 7:17 UTC (permalink / raw) To: Doug Evans; +Cc: tromey, gdb-patches, ccoutant, saugustine > From: Doug Evans <dje@google.com> > Date: Thu, 17 Jan 2013 13:04:42 -0800 > Cc: gdb-patches@sourceware.org, > ccoutant@google.com, > saugustine@google.com > > How's this? > > Eli, this has a doc change. That part is OK, thanks. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFA, doc RFA] Work around binutils/15021 2013-01-17 21:04 ` [RFA, doc RFA] " Doug Evans 2013-01-18 7:17 ` Eli Zaretskii @ 2013-01-18 14:32 ` Tom Tromey 1 sibling, 0 replies; 14+ messages in thread From: Tom Tromey @ 2013-01-18 14:32 UTC (permalink / raw) To: Doug Evans; +Cc: eliz, gdb-patches, ccoutant, saugustine >>>>> "Doug" == Doug Evans <dje@google.com> writes: >> If follow_die_sig can be called when one TU refers to another TU, then >> it seems like the TU could have a non-empty 'imported_symtabs', meaning >> that the loop here should also iterate over TUs. Doug> How's this? Looks good to me. Tom ^ permalink raw reply [flat|nested] 14+ messages in thread
* Regressions with dwz [Re: [RFA] Work around binutils/15021] 2013-01-16 23:21 [RFA] Work around binutils/15021 Doug Evans 2013-01-17 17:53 ` Tom Tromey @ 2013-01-24 14:59 ` Jan Kratochvil [not found] ` <CADPb22SoND17XeXBL2N+-DXf+yKuWe4PJEXR86qT06-q_LA+7g@mail.gmail.com> 2013-06-09 17:09 ` [RFA] Work around binutils/15021 Jan Kratochvil 2 siblings, 1 reply; 14+ messages in thread From: Jan Kratochvil @ 2013-01-24 14:59 UTC (permalink / raw) To: Doug Evans; +Cc: gdb-patches, tromey, ccoutant, saugustine On Thu, 17 Jan 2013 00:21:29 +0100, Doug Evans wrote: > Regression tested with gdb-generated .gdb_index version 7 (by hacking the > gdb-under-test to generate version 7), version 8, with dwz, and with gold. ceb4ee95539d6324ca0f307ba729ea660ed5d1bd is the first bad commit commit ceb4ee95539d6324ca0f307ba729ea660ed5d1bd Author: Doug Evans <dje@google.com> Date: Wed Jan 23 18:47:47 2013 +0000 Work around binutils/15021. * dwarf2read.c (dwarf2_per_cu_data): Split imported_symtabs and type_unit_group out of union s. All uses updated. (read_index_from_section): Watch for index version 8. (follow_die_sig): If using .gdb_index version <= 7, record the TU as an imported symtab. (write_psymtabs_to_index): Increment version number to 8. doc/ * gdb.texinfo (Index Section Format): Document .gdb_index version 8. Running ./gdb.cp/namespace.exp ... FAIL: gdb.cp/namespace.exp: whatis C::cOtherFileType FAIL: gdb.cp/namespace.exp: whatis ::C::cOtherFileType FAIL: gdb.cp/namespace.exp: print AAA::ALPHA Running ./gdb.cp/derivation.exp ... FAIL: gdb.cp/derivation.exp: ptype A::value_type FAIL: gdb.cp/derivation.exp: whatis A::value_type FAIL: gdb.cp/derivation.exp: p (A::value_type) 0 FAIL: gdb.cp/derivation.exp: ptype D::value_type FAIL: gdb.cp/derivation.exp: whatis D::value_type FAIL: gdb.cp/derivation.exp: p (D::value_type) 0 FAIL: gdb.cp/derivation.exp: ptype E::value_type FAIL: gdb.cp/derivation.exp: whatis E::value_type FAIL: gdb.cp/derivation.exp: p (E::value_type) 0 FAIL: gdb.cp/derivation.exp: ptype F::value_type FAIL: gdb.cp/derivation.exp: whatis F::value_type FAIL: gdb.cp/derivation.exp: p (F::value_type) 0 FAIL: gdb.cp/derivation.exp: ptype Z::value_type FAIL: gdb.cp/derivation.exp: whatis Z::value_type FAIL: gdb.cp/derivation.exp: p (Z::value_type) 0 FAIL: gdb.cp/derivation.exp: ptype ZZ::value_type FAIL: gdb.cp/derivation.exp: whatis ZZ::value_type FAIL: gdb.cp/derivation.exp: p (ZZ::value_type) 0 Running ./gdb.base/completion.exp ... FAIL: gdb.base/completion.exp: complete ptype enum some_ Reproducible on Fedora {18,Rawhide} x86_64 runtest-dwz: #! /bin/sh if [ -x ../gdb ];then export GDB="$PWD/../gdb -data-directory $PWD/../data-directory" fi exec runtest CC_FOR_TARGET=/bin/sh\ $PWD/../contrib/cc-with-tweaks.sh\ -m\ gcc CXX_FOR_TARGET=/bin/sh\ $PWD/../contrib/cc-with-tweaks.sh\ -m\ g++ "$@" $ runtest-dwz gdb.base/completion.exp gdb.cp/derivation.exp gdb.cp/namespace.exp Regards, Jan ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CADPb22SoND17XeXBL2N+-DXf+yKuWe4PJEXR86qT06-q_LA+7g@mail.gmail.com>]
* Re: Regressions with dwz [Re: [RFA] Work around binutils/15021] [not found] ` <CADPb22SoND17XeXBL2N+-DXf+yKuWe4PJEXR86qT06-q_LA+7g@mail.gmail.com> @ 2013-01-24 17:16 ` Jan Kratochvil 2013-01-24 19:08 ` Jan Kratochvil 0 siblings, 1 reply; 14+ messages in thread From: Jan Kratochvil @ 2013-01-24 17:16 UTC (permalink / raw) To: Doug Evans; +Cc: Sterling Augustine, Cary Coutant, tromey, gdb-patches On Thu, 24 Jan 2013 18:14:02 +0100, Doug Evans wrote: > Not sure I tested dwz with -m. > At any rate I get the same failures with a tree checked out with > -D2013-01-22 (i.e., before my patch). I get full PASS for ceb4ee95539d6324ca0f307ba729ea660ed5d1bd^ (see the trailing '^'). I can troubleshoot it if you do not have Fedora 18 nearby. Jan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regressions with dwz [Re: [RFA] Work around binutils/15021] 2013-01-24 17:16 ` Jan Kratochvil @ 2013-01-24 19:08 ` Jan Kratochvil 2013-01-30 20:41 ` Tom Tromey 0 siblings, 1 reply; 14+ messages in thread From: Jan Kratochvil @ 2013-01-24 19:08 UTC (permalink / raw) To: Doug Evans; +Cc: Sterling Augustine, Cary Coutant, tromey, gdb-patches On Thu, 24 Jan 2013 18:16:08 +0100, Jan Kratochvil wrote: > On Thu, 24 Jan 2013 18:14:02 +0100, Doug Evans wrote: > > Not sure I tested dwz with -m. > > At any rate I get the same failures with a tree checked out with > > -D2013-01-22 (i.e., before my patch). > > I get full PASS for ceb4ee95539d6324ca0f307ba729ea660ed5d1bd^ (see the > trailing '^'). Correction: It was already broken just with the contrib/cc-with-tweaks.sh flag "-m" (dwz). But with "-m -i" (dwz together with .gdb_index) this commit regressed it. ("-m -i" is what gets exposed in Fedora packaging.) Sure the "-m" issue is a bug, unaware now whether in dwz or in GDB (guessing GDB). Thanks, Jan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Regressions with dwz [Re: [RFA] Work around binutils/15021] 2013-01-24 19:08 ` Jan Kratochvil @ 2013-01-30 20:41 ` Tom Tromey 0 siblings, 0 replies; 14+ messages in thread From: Tom Tromey @ 2013-01-30 20:41 UTC (permalink / raw) To: Jan Kratochvil; +Cc: Doug Evans, Sterling Augustine, Cary Coutant, gdb-patches Jan> Sure the "-m" issue is a bug, unaware now whether in dwz or in GDB Jan> (guessing GDB). See http://sourceware.org/bugzilla/show_bug.cgi?id=15028 I have patches for a couple of gdb problems; Jakub is looking at one possible dwz bug; and I still don't have a patch for the namespace problem that comes up if you fix the other bugs. Tom ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFA] Work around binutils/15021 2013-01-16 23:21 [RFA] Work around binutils/15021 Doug Evans 2013-01-17 17:53 ` Tom Tromey 2013-01-24 14:59 ` Regressions with dwz [Re: [RFA] Work around binutils/15021] Jan Kratochvil @ 2013-06-09 17:09 ` Jan Kratochvil 2013-06-12 9:49 ` Doug Evans 2 siblings, 1 reply; 14+ messages in thread From: Jan Kratochvil @ 2013-06-09 17:09 UTC (permalink / raw) To: Doug Evans; +Cc: gdb-patches, tromey, ccoutant, saugustine, Jakub Jelinek Hello Doug, On Thu, 17 Jan 2013 00:21:29 +0100, Doug Evans wrote: > + This is also used to work around a difference between the way gold > + generates .gdb_index version <=7 and the way gdb does. Arguably this > + is a gold bug. For symbols coming from TUs, gold records in the index > + the CU that includes the TU instead of the TU itself. This breaks > + dw2_lookup_symbol: It assumes that if the index says symbol X lives > + in CU/TU Y, then one need only expand Y and a subsequent lookup in Y > + will find X. Alas TUs live in their own symtab, so after expanding CU Y > + we need to look in TU Z to find X. Fortunately, this is akin to > + DW_TAG_imported_unit, so we just use the same mechanism: For > + .gdb_index version <=7 this also records the TUs that the CU referred > + to. Concurrently with this change gdb was modified to emit version 8 > + indices so we only pay a price for gold generated indices. */ what is the gold bug? According to the description I would expect from gold a line [773] C: 1 [no symbol information] but there is a line similar to what contains a gdb-produced index 7/8. [773] C: T0 [no symbol information] dwz currently supports at most version 7 so I am not sure if there is any change needed in dwz for version 8. Thanks, Jan echo 'void f() {}' >tu0.C;echo 'class C {} c; int main() {}' >tu.C;for i in tu0 tu;do g++ -c -o $i.o $i.C -Wall -g -fdebug-types-section;done;g++ -o tu tu0.o tu.o -Wall;ld.gold -o tugold tu0.o tu.o --gdb-index;cp tu tu7;~/redhat/gdb-test-gdbindex7/gdb-add-index ./tu7;cp tu tu8;gdb-add-index tu8 ==> tu0.C <== --- CU 0 void f() {} ==> tu.C <== --- CU 1 class C {} c; int main() {} readelf --debug-dump=gdb_index tu{7,8} # There is no difference in these ------------------------------------------------------------------------------ Contents of the .gdb_index section: Version {7,8} CU table: [ 0] 0x0 - 0x48 [ 1] 0x49 - 0xb1 TU table: [ 0] 0x0 0x25 e5fcb7a195b2f213 Address table: 00000000004005b0 00000000004005b6 0 00000000004005b8 00000000004005c3 1 Symbol table: [489] main: 1 [global function] [754] int: 1 [static type] [773] C: T0 [global type] [1010] c: 1 [global variable] [1013] f: 0 [global function] ------------------------------------------------------------------------------ readelf --debug-dump=gdb_index tugold ------------------------------------------------------------------------------ Contents of the .gdb_index section: Version 5 CU table: [ 0] 0x0 - 0x48 [ 1] 0x49 - 0xb1 TU table: [ 0] 0x0 0x25 e5fcb7a195b2f213 Address table: 00000000004000e8 00000000004000ee 0 00000000004000f0 00000000004000fb 1 Symbol table: [489] main: 1 [no symbol information] [754] int: 1 [no symbol information] [773] C: T0 [no symbol information] [1010] c: 1 [no symbol information] [1013] f: 0 [no symbol information] ------------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFA] Work around binutils/15021 2013-06-09 17:09 ` [RFA] Work around binutils/15021 Jan Kratochvil @ 2013-06-12 9:49 ` Doug Evans 2013-06-12 18:29 ` Jan Kratochvil 0 siblings, 1 reply; 14+ messages in thread From: Doug Evans @ 2013-06-12 9:49 UTC (permalink / raw) To: Jan Kratochvil Cc: gdb-patches, Tom Tromey, Cary Coutant, Sterling Augustine, Jakub Jelinek On Sat, Jun 8, 2013 at 9:04 AM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote: > Hello Doug, > > On Thu, 17 Jan 2013 00:21:29 +0100, Doug Evans wrote: >> + This is also used to work around a difference between the way gold >> + generates .gdb_index version <=7 and the way gdb does. Arguably this >> + is a gold bug. For symbols coming from TUs, gold records in the index >> + the CU that includes the TU instead of the TU itself. This breaks >> + dw2_lookup_symbol: It assumes that if the index says symbol X lives >> + in CU/TU Y, then one need only expand Y and a subsequent lookup in Y >> + will find X. Alas TUs live in their own symtab, so after expanding CU Y >> + we need to look in TU Z to find X. Fortunately, this is akin to >> + DW_TAG_imported_unit, so we just use the same mechanism: For >> + .gdb_index version <=7 this also records the TUs that the CU referred >> + to. Concurrently with this change gdb was modified to emit version 8 >> + indices so we only pay a price for gold generated indices. */ > > what is the gold bug? > > According to the description I would expect from gold a line > [773] C: 1 [no symbol information] > > but there is a line similar to what contains a gdb-produced index 7/8. > [773] C: T0 [no symbol information] Hi. The gold "bug" is that, when using pubnames(/pubtypes) to generate the index, gold doesn't have sufficient info to generate as "accurate" a .gdb_index ("accurate" as in: the CU will have a DW_AT_GNU_pubtypes attribute when it would be better if the TU had that attribute). If those sections are missing then gold falls back to reading all the debug info and using that to generate the index, and when it does that it can generate a better index, and I'm guessing that's what you're seeing. > dwz currently supports at most version 7 so I am not sure if there is any > change needed in dwz for version 8. There is no change in the file format or semantics between 7 and 8, so no change should be needed for dwz. [I didn't know dwz dealt with .gdb_index - something for my TIL file. :-)] > > > Thanks, > Jan > > > echo 'void f() {}' >tu0.C;echo 'class C {} c; int main() {}' >tu.C;for i in tu0 tu;do g++ -c -o $i.o $i.C -Wall -g -fdebug-types-section;done;g++ -o tu tu0.o tu.o -Wall;ld.gold -o tugold tu0.o tu.o --gdb-index;cp tu tu7;~/redhat/gdb-test-gdbindex7/gdb-add-index ./tu7;cp tu tu8;gdb-add-index tu8 > > ==> tu0.C <== --- CU 0 > void f() {} > > ==> tu.C <== --- CU 1 > class C {} c; int main() {} > > > readelf --debug-dump=gdb_index tu{7,8} # There is no difference in these > ------------------------------------------------------------------------------ > Contents of the .gdb_index section: > Version {7,8} > > CU table: > [ 0] 0x0 - 0x48 > [ 1] 0x49 - 0xb1 > > TU table: > [ 0] 0x0 0x25 e5fcb7a195b2f213 > > Address table: > 00000000004005b0 00000000004005b6 0 > 00000000004005b8 00000000004005c3 1 > > Symbol table: > [489] main: 1 [global function] > [754] int: 1 [static type] > [773] C: T0 [global type] > [1010] c: 1 [global variable] > [1013] f: 0 [global function] > ------------------------------------------------------------------------------ > > readelf --debug-dump=gdb_index tugold > ------------------------------------------------------------------------------ > Contents of the .gdb_index section: > Version 5 > > CU table: > [ 0] 0x0 - 0x48 > [ 1] 0x49 - 0xb1 > > TU table: > [ 0] 0x0 0x25 e5fcb7a195b2f213 > > Address table: > 00000000004000e8 00000000004000ee 0 > 00000000004000f0 00000000004000fb 1 > > Symbol table: > [489] main: 1 [no symbol information] > [754] int: 1 [no symbol information] > [773] C: T0 [no symbol information] > [1010] c: 1 [no symbol information] > [1013] f: 0 [no symbol information] > ------------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFA] Work around binutils/15021 2013-06-12 9:49 ` Doug Evans @ 2013-06-12 18:29 ` Jan Kratochvil 2013-06-12 19:50 ` Cary Coutant 0 siblings, 1 reply; 14+ messages in thread From: Jan Kratochvil @ 2013-06-12 18:29 UTC (permalink / raw) To: Doug Evans Cc: gdb-patches, Tom Tromey, Cary Coutant, Sterling Augustine, Jakub Jelinek On Wed, 12 Jun 2013 01:39:43 +0200, Doug Evans wrote: > The gold "bug" is that, when using pubnames(/pubtypes) to generate the > index, gold doesn't have sufficient info to generate as "accurate" a > .gdb_index ("accurate" as in: the CU will have a DW_AT_GNU_pubtypes > attribute when it would be better if the TU had that attribute). > If those sections are missing then gold falls back to reading all the > debug info and using that to generate the index, and when it does that > it can generate a better index, and I'm guessing that's what you're > seeing. I get the same .gdb_index content from gold even when I use -gpubnames. > There is no change in the file format or semantics between 7 and 8, so > no change should be needed for dwz. But I am fine enough with this reply. Thanks! Jan ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFA] Work around binutils/15021 2013-06-12 18:29 ` Jan Kratochvil @ 2013-06-12 19:50 ` Cary Coutant 0 siblings, 0 replies; 14+ messages in thread From: Cary Coutant @ 2013-06-12 19:50 UTC (permalink / raw) To: Jan Kratochvil Cc: Doug Evans, gdb-patches, Tom Tromey, Sterling Augustine, Jakub Jelinek >> The gold "bug" is that, when using pubnames(/pubtypes) to generate the >> index, gold doesn't have sufficient info to generate as "accurate" a >> .gdb_index ("accurate" as in: the CU will have a DW_AT_GNU_pubtypes >> attribute when it would be better if the TU had that attribute). >> If those sections are missing then gold falls back to reading all the >> debug info and using that to generate the index, and when it does that >> it can generate a better index, and I'm guessing that's what you're >> seeing. > > I get the same .gdb_index content from gold even when I use -gpubnames. Gold ignores the pubnames sections unless there's a DW_AT_GNU_pubtypes attribute with a reference class form. If it's just a flag (as trunk GCC generates), that's not sufficient. (I intend to fix gold to work with this, but haven't done it yet.) On top of that, GCC doesn't put that attribute in the TUs at all, so gold will always parse the debug info in each TU. I think GCC needs to be fixed to emit that attribute in each TU. -cary ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-06-12 18:29 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-16 23:21 [RFA] Work around binutils/15021 Doug Evans
2013-01-17 17:53 ` Tom Tromey
2013-01-17 18:42 ` Doug Evans
2013-01-17 21:04 ` [RFA, doc RFA] " Doug Evans
2013-01-18 7:17 ` Eli Zaretskii
2013-01-18 14:32 ` Tom Tromey
2013-01-24 14:59 ` Regressions with dwz [Re: [RFA] Work around binutils/15021] Jan Kratochvil
[not found] ` <CADPb22SoND17XeXBL2N+-DXf+yKuWe4PJEXR86qT06-q_LA+7g@mail.gmail.com>
2013-01-24 17:16 ` Jan Kratochvil
2013-01-24 19:08 ` Jan Kratochvil
2013-01-30 20:41 ` Tom Tromey
2013-06-09 17:09 ` [RFA] Work around binutils/15021 Jan Kratochvil
2013-06-12 9:49 ` Doug Evans
2013-06-12 18:29 ` Jan Kratochvil
2013-06-12 19:50 ` Cary Coutant
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox