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