Re: [google/gcc-4_7] Backport Fission patches from trunk (issue 6405076)
On 2012/07/23 21:21:28, Cary wrote: This patch is for the google/gcc-4_7 branch. It backports five Fission patches from trunk, with two minor differences: - The DW_AT_GNU_pubnames and DW_AT_GNU_pubtypes attributes are both generated, and provide the offset to the corresponding pubnames/pubtypes section. This is done for compatibility with the gold linker, which does not yet support the flag form. - Enumerator names are placed in .debug_pubtypes instead of .debug_pubnames. In trunk with -fdebug_types_section enabled, enumerators were missing from the pubnames table. This patch is OK for Google branches. We'll need to update top of trunk pubnames to match. Sterling http://codereview.appspot.com/6405076/
Re: [Dwarf Patch] Implement split debug info proposal (issue 6305113)
On 2012/07/20 00:37:15, Cary wrote: http://codereview.appspot.com/6305113/diff/3001/gcc/dwarf2out.c File gcc/dwarf2out.c (right): http://codereview.appspot.com/6305113/diff/3001/gcc/dwarf2out.c#newcode8517 gcc/dwarf2out.c:8517: Should use SKELETON_COMP_DIE_ABBREV here instead of 1. http://codereview.appspot.com/6305113/diff/3001/gcc/dwarf2out.c#newcode8602 gcc/dwarf2out.c:8602: const unsigned char *cp2; I don't think this comment applies here. I have fixed both of these issues in my local copy, and will post a revision after I received feedback from Jason. Sterling http://codereview.appspot.com/6305113/
Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)
On 2012/06/01 17:58:41, saugustine wrote: The enclosed patch updates the earlier patch to address all of the feedback I have gotten regarding generating pubnames. It fixes the offset problem in the pubtypes table; switches DW_AT_pubtypes to a flag and so on. It also adds and documents a new option -g[no-]pubtypes which allows users to generate pubtypes even if the target disables them by default. Tested with bootstrap and running the test_pubnames_and_indices.py script recently contributed to the GDB project. Ping? I have another patch that depends on this one coming. http://codereview.appspot.com/6197069/
Re: [google/gcc-4_6] Fix -gfission issue in index_location_lists (issue 6248072)
This is OK for google/gcc-4_6. http://codereview.appspot.com/6248072/
Re: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)
Hi Jasaon,
Thanks so much for reviewing this patch. I realize it is a lot to see.
The motivation and new dwarf attributes and tags all stem from the debug
fission project as described at http://gcc.gnu.org/wiki/DebugFission. I
have several more patches dealing with fission coming.
Fission has been discussed in the Dwarf standardization meetings.
Thanks again, I am happy to make the changes you deem necessary.
http://codereview.appspot.com/6197069/diff/1/gcc/dwarf2out.c
File gcc/dwarf2out.c (left):
http://codereview.appspot.com/6197069/diff/1/gcc/dwarf2out.c#oldcode22231
gcc/dwarf2out.c:22231: FOR_EACH_VEC_ELT (pubname_entry, pubtype_table,
i, p)
On 2012/05/18 22:39:18, Jason Merrill wrote:
You don't seem to have added anything to output_pubnames to avoid
emitting
entries for pruned types.
The code I removed doesn't deal with omitting individual entries.
Instead, it decides whether to emit the pubtypes section at all--if it
is empty, then don't emit it. Pruned entries are handled as they always
were in output_pubnames.
What this code did was to check if the pubtypes section was emptied via
pruning. If it was, then don't emit it.
However, now that there is the DW_AT_GNU_pubtypes attribute that points
to the section, we need to emit the label no matter what. The presence
of this attribute helps the consumer know the difference between No
pubtypes were present in the source and The compiler didn't generate
pubtypes.
http://codereview.appspot.com/6197069/diff/1/gcc/dwarf2out.c
File gcc/dwarf2out.c (right):
http://codereview.appspot.com/6197069/diff/1/gcc/dwarf2out.c#newcode8070
gcc/dwarf2out.c:8070: add_AT_lineptr (die, DW_AT_GNU_pubnames,
debug_pubnames_section_label);
On 2012/05/18 22:39:18, Jason Merrill wrote:
What are these attributes for? Is there a proposal to add them?
pubnames/types
are used for lookup from a name to a DIE, so there seems to be no
reason to have
a pointer the other way.
The entire motivation for this patch, including the proposed new
attributes is at:
http://gcc.gnu.org/wiki/DebugFission
In particular, the section titled, Building a GDB Index.
(Unfortunately, there isn't an anchor to that section easily linkable.)
This was discussed at the past couple of dwarf standardization meetings.
http://codereview.appspot.com/6197069/diff/1/gcc/dwarf2out.c#newcode8162
gcc/dwarf2out.c:8162: || is_cu_die (die-die_parent) || is_namespace_die
(die-die_parent))
On 2012/05/18 22:39:18, Jason Merrill wrote:
The DWARF standard says that pubnames is for names with global scope;
this
change would add namespace-scope statics as well.
I am matching what gold and gdb do when building the gdb index. I
suppose Cary will need to add this subtle change to the proposal, and I
can also guard it with dwarf_split_debug_info.
http://codereview.appspot.com/6197069/diff/1/gcc/dwarf2out.c#newcode9177
gcc/dwarf2out.c:9177: add_pubtype (type, base_type_result);
On 2012/05/18 22:39:18, Jason Merrill wrote:
Why do we need pubtype entries for base types?
Same as above--to make these addable to the index, which in turn makes
gdb faster. I'll add this to the note to Cary.
http://codereview.appspot.com/6197069/diff/1/gcc/dwarf2out.c#newcode19010
gcc/dwarf2out.c:19010: /* Bypass dwarf2_name's check for DECL_NAMELESS.
*/
On 2012/05/18 22:39:18, Jason Merrill wrote:
Why bypass the DECL_NAMELESS check?
So objects within anonymous namespaces get pubnames:
namespace { void some_function...
Can you point me at discussion about adding enumerators and namespaces
to
pubnames? Historically it has just been for things with addresses
(the standard
says objects and functions).
This is all about making every name gdb might need public. Yet another
note to add to the proposal, I suppose. I will see to it that Cary does.
http://codereview.appspot.com/6197069/
Re: [google/4.6] Fix problems with -gfission (issue 5844043)
On 2012/03/16 02:07:02, Cary wrote: For google/gcc-4_6 branch. This patch fixes several problems with -gfission: - Bad index for range list in the compile unit DIE. - DW_AT_ranges attribute for compile unit in the wrong file. - Incorrect size for skeleton type unit DIEs. - Wrote location expression using DW_OP_addr to DWO file. - Emitted skeleton debug section even when there is no debug info. Tested: bootstrap, gcc regression tests, hand testing on -gfission test cases. These are OK for google 4_6. http://codereview.appspot.com/5844043/
Re: [google/4.6] Fix problem where -gfission emits duplicate strings (issue 5824050)
On 2012/03/14 18:15:25, Cary wrote:
This is for the google/gcc-4_6 branch only.
Fix output_indirect_string so that it does not output strings that
have already been written to the .debug_str.dwo section.
This is a backport of part of an unrelated change from upstream 4.7:
http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00130.html
Tested: bootstrap, core, mantle, crust (in progress).
2012-03-14 Cary Coutant mailto:ccout...@google.com
* dwarf2out.c (output_indirect_string): Check for DW_FORM_strp
instead of presence of label and non-zero refcount.
Index: dwarf2out.c
===
--- dwarf2out.c (revision 185269)
+++ dwarf2out.c (working copy)
@@ -23042,7 +23042,7 @@ output_indirect_string (void **h, void *
{
struct indirect_string_node *node = (struct indirect_string_node *)
*h;
- if (node-label node-refcount)
+ if (node-form == DW_FORM_strp)
{
switch_to_section (debug_str_section);
ASM_OUTPUT_LABEL (asm_out_file, node-label);
--
This patch is available for review at
http://codereview.appspot.com/5824050
This is OK for google branches.
http://codereview.appspot.com/5824050/
Re: [google] Add -gfission support to GCC (issue 5754090)
On 2012/03/12 21:32:46, Cary wrote: [Revised patch to fix problem with ASM_FINAL_SPEC in the case where neither -c nor -o are specified.] Add GCC support for -gfission option. Debug info is partitioned into skeleton sections that will remain in the .o file, and dwo sections that will be moved to a .dwo file. After compilation, the gcc driver calls objcopy twice: once to extract the dwo sections into the .dwo file, and a second time to remove the sections from the .o file. For google/gcc-4_6 branch. (To be submitted for trunk soon.) I approve for google/gcc-4_6. Sterling http://codereview.appspot.com/5754090/
