<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 12:00 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "David Blaikie" <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: "<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a> Developers" <<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>>, "Eric Christopher" <<a href="mailto:echristo@google.com">echristo@google.com</a>><br>
</span><div><div class="h5">> Sent: Friday, October 17, 2014 1:39:15 PM<br>
> Subject: Re: Should -g1 mean -gline-tables-only?<br>
><br>
><br>
> On Fri, Oct 17, 2014 at 11:32 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
> ----- Original Message -----<br>
> > From: "David Blaikie" < <a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a> ><br>
> > To: "Hal Finkel" < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> > Cc: " <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a> Developers" < <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a> >,<br>
> > "Eric Christopher" < <a href="mailto:echristo@google.com">echristo@google.com</a> ><br>
> > Sent: Friday, October 17, 2014 12:49:09 PM<br>
> > Subject: Re: Should -g1 mean -gline-tables-only?<br>
> ><br>
> > On Fri, Oct 17, 2014 at 10:37 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> > wrote:<br>
> ><br>
> ><br>
> > Hi,<br>
> ><br>
> > Debugging flags are not my area of expertise, but GCC's manual says<br>
> > about -g1:<br>
> ><br>
> > [from GCC's man page]<br>
> > Level 1 produces minimal information, enough for making backtraces<br>
> > in<br>
> > parts of the program that you don't plan to debug.<br>
> > This includes descriptions of functions and external variables, but<br>
> > no information about local variables and no line numbers.<br>
> ><br>
> ><br>
> ><br>
> > Sounds similar, apart from the "and external variables" part.<br>
> ><br>
> > It'd be interesting to actually look at the output - I Suspect it<br>
> > might be a bit more verbose than Clang's (or GCC's) -gmlt, maybe<br>
> > including namespaces, mangled function names, whatever else.<br>
> ><br>
> > I think maybe Google's GCC branch has -gmlt, but maybe it's not in<br>
> > GCC proper? I don't really know/understand.<br>
> ><br>
> ><br>
> > [end from GCC's man page]<br>
> ><br>
> > and IBM's manual for xlc says about -g1:<br>
> ><br>
> > [from IBM's man page]<br>
> > Generates minimal read-only debugging information about line<br>
> > numbers<br>
> > and source file names. No program state is preserved.<br>
> ><br>
> ><br>
> > Sounds about right. Be interesting to know if that's just the line<br>
> > table itself, or the inlining info that Clang's<br>
> > -gmlt/-gline-tables-only produces as well (yeah, -gline-tables-only<br>
> > is a bit of a half truth).<br>
><br>
> How could I tell? (I believe we have some kind of dwarf-dumping<br>
> utility, but I don't know for what to look).<br>
><br>
><br>
> llvm-dwarfdump is a utility for dumping DWARF debug information.<br>
> Running it on an object file built with xlc's -g1 and see if there<br>
> are many DW_TAGs in the debug_info section (ones describing each<br>
> function, etc). If the only thing of note is the line table<br>
> (debug_line section) then it's probably not producing the inlining<br>
> info that we do in -gmlt. *shrug*<br>
><br>
> Anyway, it sounds like xlc's -g1 might be a bit less than Clang's<br>
> -gmlt and GCC's -g1 might be a bit more than Clang's -gmlt. So if<br>
> those are both valid interpretations of -g1, Clang's -gmlt should<br>
> fit right in ;)<br>
><br>
<br>
</div></div>I tried your example using xlc:<br>
<br>
$ cat /tmp/t1.c<br>
<span class="">void f1() { } void __attribute__((always_inline)) f2() { f1(); } void f3() { f2(); }<br>
</span>$ bgxlc -g1 -o /tmp/t1.o /tmp/t1.c -c<br>
$ llvm-dwarfdump /tmp/t1.o<br>
/tmp/t1.o:      file format ELF64-ppc64<br>
<br>
.debug_abbrev contents:<br>
Abbrev table for offset: 0x00000000<br>
[1] DW_TAG_compile_unit DW_CHILDREN_no<br>
        DW_AT_name      DW_FORM_string<br>
        DW_AT_stmt_list DW_FORM_data8<br>
        DW_AT_low_pc    DW_FORM_addr<br>
        DW_AT_high_pc   DW_FORM_addr<br>
        DW_AT_language  DW_FORM_data1<br>
        DW_AT_comp_dir  DW_FORM_string<br>
        DW_AT_producer  DW_FORM_string<br>
<br>
<br>
.debug_abbrev.dwo contents:<br>
< EMPTY ><br>
<br>
.debug_info contents:<br>
<br>
.debug_loc contents:<br>
<br>
.debug_loc.dwo contents:<br>
<br>
.debug_frame contents:<br>
<br>
00000000 0000000c ffffffff CIE<br>
  Version:               1<br>
  Augmentation:          ""<br>
  Code alignment factor: 4<br>
  Data alignment factor: -8<br>
  Return address column: 65<br>
<br>
  DW_CFA_def_cfa:<br>
<br>
00000010 00000024 00000000 FDE cie=00000000 pc=00000000...0000001c<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_offset:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_def_cfa_offset:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_def_cfa_register:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_remember_state:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_restore:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_restore_state:<br>
<br>
00000038 0000002c 00000000 FDE cie=00000000 pc=00000000...00000034<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_offset:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_offset_extended_sf:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_def_cfa_offset:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_def_cfa_register:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_remember_state:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_restore:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_restore_state:<br>
  DW_CFA_nop:<br>
  DW_CFA_nop:<br>
  DW_CFA_nop:<br>
  DW_CFA_nop:<br>
<br>
00000068 0000002c 00000000 FDE cie=00000000 pc=00000000...00000034<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_offset:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_offset_extended_sf:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_def_cfa_offset:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_def_cfa_register:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_remember_state:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_restore:<br>
  DW_CFA_advance_loc:<br>
  DW_CFA_restore_state:<br>
  DW_CFA_nop:<br>
  DW_CFA_nop:<br>
  DW_CFA_nop:<br>
  DW_CFA_nop:<br>
<br>
<br>
.debug_aranges contents:<br>
Address Range Header: length = 0x0000002c, version = 0x0002, cu_offset = 0x00000000, addr_size = 0x08, seg_size = 0x00<br>
[0x0000000000000000 - 0x00000000000000dc)<br>
<br>
.debug_line contents:<br></blockquote><div><br>I suspect there's actually a line table here, but since there's no compile unit, llvm-dwarfdump has trouble printing the line table. objdump -h should at least demonstrate that there section is non-empty.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
.debug_line.dwo contents:<br>
<br>
.debug_str contents:<br>
<br>
.debug_ranges contents:<br>
<br>
.debug_pubnames contents:<br>
length = 0xffffffff version = 0x0000 unit_offset = 0x00000000 unit_size = 0x001a0002<br>
Offset     Name<br>
length = 0x00000000 version = 0x0000 unit_offset = 0x00000000 unit_size = 0x00970000<br>
Offset     Name<br>
length = 0x00000000 version = 0x0000 unit_offset = 0x00000000 unit_size = 0x00000000<br>
Offset     Name<br></blockquote><div><br>Weird.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
.debug_pubtypes contents:<br>
length = 0xffffffff version = 0x0000 unit_offset = 0x00000000 unit_size = 0x001a0002<br>
Offset     Name<br>
length = 0x00000000 version = 0x0000 unit_offset = 0x00000000 unit_size = 0x00970000<br>
Offset     Name<br>
length = 0x00000000 version = 0x0000 unit_offset = 0x00000000 unit_size = 0x00000000<br>
Offset     Name<br>
<br>
.debug_gnu_pubnames contents:<br>
<br>
.debug_gnu_pubtypes contents:<br>
<br>
This seems to contain even less information than doing the same thing with gcc (which has a bunch of DW_TAG_subprogram sections too).<br></blockquote><div><br>Yeah, seems to be a pretty random variation - I hope/assume/guess at least in both (all, including LLVM) cases, they actually include the line table (if my guess about xlc's output is correct). The subprogram information is uncertain between all three... <br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks again,<br>
Hal<br>
<div class="HOEnZb"><div class="h5"><br>
> - David<br>
><br>
><br>
><br>
> Thanks again,<br>
> Hal<br>
><br>
><br>
><br>
> ><br>
> ><br>
> > [end from IBM's man page]<br>
> ><br>
> > this sounds to me a lot like what -gline-tables-only does. Is there<br>
> > a<br>
> > reason we don't alias -g1 to -gline-tables-only? Currently, the<br>
> > code<br>
> > in Clang::ConstructJob treats it just like -g.<br>
> ><br>
> > Thanks again,<br>
> > Hal<br>
> ><br>
> > --<br>
> > Hal Finkel<br>
> > Assistant Computational Scientist<br>
> > Leadership Computing Facility<br>
> > Argonne National Laboratory<br>
> ><br>
> ><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
><br>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div></div>