From: "David Blaikie" <dblaikie@gmail.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "cfe-dev@cs.uiuc.edu Developers" <cfe-dev@cs.uiuc.edu>, "Eric Christopher" <echristo@google.com>
Sent: Friday, October 17, 2014 1:39:15 PM
Subject: Re: Should -g1 mean -gline-tables-only?
> From: "David Blaikie" < dblaikie@gmail.com >
> To: "Hal Finkel" < hfinkel@anl.gov >
> Cc: " cfe-dev@cs.uiuc.edu Developers" < cfe-dev@cs.uiuc.edu >,
> "Eric Christopher" < echristo@google.com >
> Sent: Friday, October 17, 2014 12:49:09 PM
> Subject: Re: Should -g1 mean -gline-tables-only?
>
>
>
> 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).
Thanks again,
Hal