Re: [Dwarf-Discuss] Is this legal DWARF, and if so, what does it mean?

[John DelSignore]

Hi Ron, Thanks for the reply, in-line below... Ron Brender wrote: 1. I am not enough of an C++ lawyer to comment on the meaning of lexical blocks inside "std". But I don't recall that the formal definition of "std" has any such blocks--if not, the presence here is either wrong or the sloppy remains of some block nested in something else that did not get properly cleaned up. The lack of anything else inside "std" suggests that some compilation option may be at play to throttle DWARF production but is not quite consistently applied. Sorry if I wasn't clear, but the lexical blocks in question did appear to be surrounded by objects I'd expect to be in "std::", things like variables, inlined subroutines, formal parameters, etc. So, "std" wasn't empty, but within "std" the DWARF for first lexical block in my original email had only an empty second lexical block. But yes, the blocks did look like something the compiler failed to clean up. 2. As a DWARF lawyer (which is how I earn my big bucks) I would say that an address range that is not within its containing block is an error. At best it suggests poor QOI. I agree with you. And if it is legal, I'm not sure how the debugger should show it to a user... For example, assume that there were variables in both disjoint blocks. When the program is stopped at the inner block, are the variables in the outer block active or not? The nesting implies "yes", but the address ranges imply "no". What compilation options produce this? I don't know, but I can have our Support people ask the customer. The source being compiled does not affect "std", of course, but does the compiler produce this same description of "std" for all sources? Ah, good question. The library is huge, 679MB long, and the readelf output is 4.6GB, but I did find another occurrence of the strange lexical block nesting inside the same compilation unit, but this time is was within a class, not "std":  <1><366edc>: Abbrev Number: 4 (DW_TAG_class_type)      DW_AT_decl_line   : 26         DW_AT_decl_column : 7         DW_AT_decl_file   : 115         DW_AT_accessibility: 1    (public)      DW_AT_byte_size   : 72         DW_AT_name        : VPScreenWindow    ...LOTS OF DWARF REMOVED...  <2><367e64>: Abbrev Number: 37 (DW_TAG_lexical_block)      DW_AT_decl_line   : 1370         DW_AT_decl_column : 79         DW_AT_decl_file   : 1         DW_AT_low_pc      : 0xb048c         DW_AT_high_pc     : 0xb0b0a     <3><367e79>: Abbrev Number: 38 (DW_TAG_lexical_block)      DW_AT_decl_line   : 1385         DW_AT_decl_column : 97         DW_AT_decl_file   : 1         DW_AT_low_pc      : 0xb05ea         DW_AT_high_pc     : 0xb0b0a    I guess that implies that it's not necessarily "std" related. The real expert, of course, should be our very own John Bishop... Yes, I was hoping he would be able to explain what's going on. Cheers, John D. My 2 cents... Ron On Mon, Sep 15, 2014 at 1:32 PM, John DelSignore <john.delsign...@roguewave.com> wrote: Hi, TotalView has a customer that has C++ code that produces the following DWARF with the Intel 12.1 compiler:  <0><1192a2>: Abbrev Number: 1 (DW_TAG_compile_unit)      DW_AT_comp_dir    : ...SNIPPED...      DW_AT_language    : 4    (C++)      DW_AT_name        : ...SNIPPED...      DW_AT_producer    : Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.1 Build 20110811  Fixes SameLinkageName MemberPointers          DW_AT_stmt_list   : 0x5d20     <1><119376>: Abbrev Number: 2 (DW_TAG_namespace)      DW_AT_name        : std    ...SNIPPED...  <2><268209>: Abbrev Number: 37 (DW_TAG_lexical_block)      DW_AT_decl_line   : 1301         DW_AT_decl_column : 79         DW_AT_decl_file   : 1         DW_AT_low_pc      : 0xb02a1         DW_AT_high_pc     : 0xb02d4     <3><26821e>: Abbrev Number: 38 (DW_TAG_lexical_block)      DW_AT_decl_line   : 1351         DW_AT_decl_column : 31         DW_AT_decl_file   : 1         DW_AT_low_pc      : 0xb03a7         DW_AT_high_pc     : 0xb03f7    <2><268234>: Abbrev Number: 16 (DW_TAG_inlined_subroutine) ...SNIPPED... Notice: The lexical block at <268209> is at "std" namespace scope. What does it mean to have a lexical block at namespace scope? Note that that lexical block contains only another lexical block at <26821e>; no subroutines or variables. The lexical block at <26821e> has an address range that is not nested inside its containing lexical block's address range. Is that legal, and if so, what does that mean? Note that that lexical block contains nothing else; no subroutines, blocks, or variables. Thanks, John D. _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org