search for: dw_at_declaration

...and constructor homing, we emit skeleton type definitions if functions have an inlined copy in the translation unit. For example in [0] where I've uploaded a couple of dexter tests for constructor homing, in partial-type/main.cpp we get: DW_TAG_class_type DW_AT_name ("foo") DW_AT_declaration (true) DW_TAG_subprogram DW_AT_linkage_name ("_ZNK3foo8asStringB5cxx11Ev") DW_AT_name ("asString") DW_AT_decl_file ("./theclass.h") DW_AT_decl_line (12) DW_AT_type (0x000014e6 "string") DW_AT_declaration...

...+-DW_AT_type DW_FORM_ref4 0x00000054 > +-00000054 DW_TAG_pointer_type > +-DW_AT_type DW_FORM_ref4 0x00000059 > +-00000059 DW_TAG_class_type "A<MONKEY>" > -DW_AT_name DW_FORM_strp "A<MONKEY>" > -DW_AT_declaration DW_FORM_flag_present > > +-00000073 DW_TAG_structure_type "C" > -DW_AT_name DW_FORM_strp "C" > +-0000007b DW_TAG_member "p" > -DW_AT_name DW_FORM_strp "p" > +-DW_AT_type DW_FORM_ref4 0x00000088 > +-00000088 DW_T...

...+-DW_AT_type DW_FORM_ref4 0x00000054 > +-00000054 DW_TAG_pointer_type > +-DW_AT_type DW_FORM_ref4 0x00000059 > +-00000059 DW_TAG_class_type "A<MONKEY>" > -DW_AT_name DW_FORM_strp "A<MONKEY>" > -DW_AT_declaration DW_FORM_flag_present > > +-00000073 DW_TAG_structure_type "C" > -DW_AT_name DW_FORM_strp "C" > +-0000007b DW_TAG_member "p" > -DW_AT_name DW_FORM_strp "p" > +-DW_AT_type DW_FORM_ref4 0x00000088 > +-00000088 DW_T...

...+-DW_AT_type DW_FORM_ref4 0x00000054 > +-00000054 DW_TAG_pointer_type > +-DW_AT_type DW_FORM_ref4 0x00000059 > +-00000059 DW_TAG_class_type "A<MONKEY>" > -DW_AT_name DW_FORM_strp "A<MONKEY>" > -DW_AT_declaration DW_FORM_flag_present > > +-00000073 DW_TAG_structure_type "C" > -DW_AT_name DW_FORM_strp "C" > +-0000007b DW_TAG_member "p" > -DW_AT_name DW_FORM_strp "p" > +-DW_AT_type DW_FORM_ref4 0x00000088 > +-00000088 DW_T...

...ervasively, this would help address pool issue too: even if a type uses an address, it would go in the CU but types referencing that type could still remain in a TU. So, barring anything else, I'm sort of inclined to just make all references to types in type units plain declarations (oh, also, DW_AT_declaration + DW_AT_name is smaller than DW_AT_declaration + DW_AT_signature (4 bytes instead of 8)). Simpler implementation, possible performance loss for the debugger (lacking the shortcut to find a type by signature instead of name lookup) and should tidy up a bunch of oddities as well as paving the way for...

...+-DW_AT_type DW_FORM_ref4 0x00000054 > +-00000054 DW_TAG_pointer_type > +-DW_AT_type DW_FORM_ref4 0x00000059 > +-00000059 DW_TAG_class_type "A<MONKEY>" > -DW_AT_name DW_FORM_strp "A<MONKEY>" > -DW_AT_declaration DW_FORM_flag_present > > +-00000073 DW_TAG_structure_type "C" > -DW_AT_name DW_FORM_strp "C" > +-0000007b DW_TAG_member "p" > -DW_AT_name DW_FORM_strp "p" > +-DW_AT_type DW_FORM_ref4 0x00000088 > +-00000088 DW_T...

Hello folks, I was interested in the support we have for the attribute form DW_FORM_implicit_const (DWARFv5 feature) in clang/LLVM. And I had some doubts wrt this. I noticed that support for this was put in here in 2017: https://rev.ng/gitlab/revng-bar-2019/llvm/commit/d9df13befcbc702e239b650dd1f55778d72b8571 >From what I could make out, the support for generating DW_FORM_implicit_const

...n then it would >> remove all other definitions(which matched by name) and set >> all references to that found definition. If it is not able to >> find a full definition then it would do nothing. i.e. if >> there are two incomplete definitions(DW_AT_declaration >> (true)) with the same name then they would not be merged. >> That is a possible improvement - to teach dsymutil to merge >> incomplete types. >> >> Huh, what does it do with extra member function definitions found >> in later de...

...es their members)) if dsymutil is able to find a full definition then it would remove all other definitions(which matched by name) and set all references to that found definition. If it is not able to find a full definition then it would do nothing. i.e. if there are two incomplete definitions(DW_AT_declaration   (true)) with the same name then they would not be merged. That is a possible improvement - to teach dsymutil to merge incomplete types. Alexey. > > But I don't have super strong feelings about the naming. > > On Tue, Sep 1, 2020 at 6:36 AM Alexey <avl.lapshin at gmail.com...

...is able to find a full definition then it would remove > all other definitions(which matched by name) and set all > references to that found definition. If it is not able to find a > full definition then it would do nothing. i.e. if there are two > incomplete definitions(DW_AT_declaration   (true)) with the same > name then they would not be merged. That is a possible improvement > - to teach dsymutil to merge incomplete types. > > Huh, what does it do with extra member function definitions found in > later definitions? (eg: struct x { template<typename T&...

...r") DW_AT_type (0x000000a9 "volatile Foo") 0x000000a1: NULL 0x000000a9: DW_TAG_volatile_type DW_AT_type (0x000000ae "Foo") 0x000000ae: DW_TAG_structure_type DW_AT_name ("Foo") DW_AT_declaration (true) 0x000000c1: DW_TAG_compile_unit DW_AT_low_pc (0x0000000000000000) DW_AT_high_pc (0x0000000000000019) 0x000000e0: DW_TAG_subprogram DW_AT_low_pc (0x0000000000000000) DW_AT_high_pc (0x0000000000000019)...

On 01.09.2020 06:27, David Blaikie wrote: > A quick note: The feature as currently proposed sounds like it's an > exact match for 'dwz'? Is there any benefit to this over the existing > dwz project? Is it different in some ways I'm not aware of? (I haven't > actually used dwz, so I might have some mistaken ideas about how it > should work) > > If

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