search for: dw_at_inline

...owing test case on Clang compiled output to compare the dwarf inline attributes in the resulting assembly output . /* Inlined inline function must have abstract DIE */ /* { dg-do compile } */ /* { dg-options "-O2 -gdwarf-2 -dA -fpreprocessed" } */ /* { dg-final { scan-assembler "3.*DW_AT_inline" } } */ #1 "test.h" inline int t() { } int q() { t(); } The testcase fails because, DW_AT_inline is not present in assembly output. Could anyone let me know why DW_AT_inline is not emitted with Clang compiled assembly output? I am aware that Clang uses C99 mode by default. In cas...

> Thanks for the reply. I have not specified optimization level explicitly > during compilation. For GCC default is O0 ie., no optimization. Do you mean > that clang uses other optimization level other than O0 ? No, here it's still -O0. However it makes no sense to compare the size of unoptimized code. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics,

Hello I am trying to run following dejaGNU testcases on Clang compiled output. /* Inlined inline function must have abstract DIE */ /* { dg-do compile } */ /* { dg-options "-O2 -gdwarf-2 -dA -fpreprocessed" } */ /* { dg-final { scan-assembler "3.*DW_AT_inline" } } */ #1 "test.h" inline int t() { } int q() { t(); } The testcase fails because, DW_AT_inline is not present in assembly output. Could anyone let me know why DW_AT_inline is not emitted ? I am aware that Clang uses C99 mode by default. -------------- next part -------------- An...

Hello Anton, Thanks for the reply. I have not specified optimization level explicitly during compilation. For GCC default is O0 ie., no optimization. Do you mean that clang uses other optimization level other than O0 ? Could you please clarify ? On Thu, Feb 16, 2012 at 6:52 PM, Anton Korobeynikov <anton at korobeynikov.info > wrote: > Hello > > > The prologue length in

...tion (if there is one?) of the inlined function (in which case I'd need to provide it... ) to find it in the symbol table, get the mangled name, and use that?) One thing I was thinking of doing as well, is that since the DW_AT_abstract_origin just points to a trivial subprogram with a name and DW_AT_inline - perhaps instead of an abstract origin, we could just use DW_AT_name directly? (with the mangled name, probably) That'd save us emitting the extra indirection and the name is uniqued already anyway. (and DW_FORM_strp is the same size as DW_FORM_ref4 (though DW_FORM_strp would mean extra reloca...

...hich >> case I'd need to provide it... ) to find it in the symbol table, get the >> mangled name, and use that?) >> >> One thing I was thinking of doing as well, is that since the >> DW_AT_abstract_origin just points to a trivial subprogram with a name and >> DW_AT_inline - perhaps instead of an abstract origin, we could just use >> DW_AT_name directly? (with the mangled name, probably) That'd save us >> emitting the extra indirection and the name is uniqued already anyway. (and >> DW_FORM_strp is the same size as DW_FORM_ref4 (though DW_FORM_s...

...bstract_origin) pointing to the equivalent lexical block entry in the abstract function. 2. Local variable entry - with abstract origin attribute pointing to the one in the abstract function, and also the location attribute. (1) DW_TAG_subprogram (abstract) DW_AT_name (= "foo") DW_AT_inline (2) LexicalBlock (3) DW_TAG_imported_module DW_AT_import (=> N) (3) DW_TAG_imported_declaration DW_AT_import (=> N::D) (3) DW_TAG_typedef DW_AT_name (= "A") DW_AT_type (=> int) (3) DW_TAG_class_type DW_AT_name (= "B") (4) DW_TAG_variable DW_AT_...

...DW_AT_decl_line .byte 1 # DW_AT_prototyped .byte 1 # DW_AT_external .long .Lfunc_begin0 # DW_AT_low_pc .long .Lfunc_end0 # DW_AT_high_pc .byte 1 # DW_AT_frame_base .byte 85 .byte 1 # DW_AT_inline .byte 5 # Abbrev [5] 0xd3:0xb DW_TAG_formal_parameter .byte 120 # DW_AT_name .byte 0 .byte 1 # DW_AT_decl_file .byte 11 # DW_AT_decl_line .long 93 # DW_AT_type .byte 1...

...l block entry in the abstract function. > > 2. Local variable entry - with abstract origin attribute pointing to > the one in the abstract function, and also the location attribute. > > > > (1) DW_TAG_subprogram (abstract) > > DW_AT_name (= "foo") > > DW_AT_inline > > > > (2) LexicalBlock > > > > (3) DW_TAG_imported_module > > DW_AT_import (=> N) > > > > (3) DW_TAG_imported_declaration > > DW_AT_import (=> N::D) > > > > (3) DW_TAG_typedef > > DW_AT_name (= "A") > > DW_AT...

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

...DW_TAG_variable DW_AT_abstract_origin (0x0000000000000096 "var") 0x00000065: NULL 0x00000073: DW_TAG_compile_unit DW_AT_stmt_list (0x00000080) 0x00000086: DW_TAG_subprogram DW_AT_name ("f") DW_AT_inline (DW_INL_inlined) 0x00000096: DW_TAG_variable DW_AT_name ("var") DW_AT_type (0x000000a9 "volatile Foo") 0x000000a1: NULL 0x000000a9: DW_TAG_volatile_type DW_AT_type (0x000000ae "Foo") 0x00000...

Folks, we work on optimization of binary size and improvement of debug info quality. To reduce the size of the binary we use -ffunction-sections so that unused code would be garbage collected. When the linker does garbage collection, a lot of abandoned debug info is left behind. Besides inflated debug info size, we ended up with overlapping address ranges and no way to say valid vs garbage