[cfe-dev] Should -g1 mean -gline-tables-only?
David Blaikie
dblaikie at gmail.com
Fri Oct 17 18:03:24 PDT 2014
On Fri, Oct 17, 2014 at 12:00 PM, 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 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:
>
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.
>
> .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
>
Weird.
>
> .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).
>
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...
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141017/33dd4c27/attachment.html>
More information about the cfe-dev
mailing list