Re: [Dwarf-Discuss] About self-referencial sized types
On 05/15/2014 06:42 PM, Jakub Jelinek wrote: Yes, I've actually already started to work with this lang-hook so we can master the DWARF information output for Ada array types (very useful!). However, it does not solve the issue of knowing what DWARF operations to output in order to compute the bounds of VLAs *without* descriptors. (see the end of my 05/14/2014 mail) You still build some trees in that langhook that describe the bounds etc. and dwarf2out.c just transforms those trees into DWARF4 expression opcodes. Absolutely. In my use case, dwarf2out.c currently doesn't know how to translate trees from the Ada frontend into DWARF opcodes. I started this thread in order to know how it should do so. -- Pierre-Marie de Rodat ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] About self-referencial sized types
On 05/16/2014 03:00 PM, Agovic, Sanimir wrote:
Indeed, therefore you have to reference a DW_TAG_variable. But
this introduces a type/variable dependency. So a record type maps
to a single variable, you end up with a 1:1 relation for this kind of
types.
The size of the debug information is already an issue, so I guess such
1:1 relations would make things worse. ;-)
Unfortunately gdb only allows constant offsets or constant dwarf expressions.
[...]
... It would work pretty well, actually! I'm not sure if this would
really be the way to go:
It is indeed quite hackish and we should rather add the necessary bits
to gdb.
Agreed.
The problem is that the member offset depend on runtime information similar
to sizeof which needs to be evaluated at runtime if the operand is a vla.
Given the following snippet:
struct foo {int a[n], int b[i];};
&((struct foo *)0)->b;
What value do you expect here? And should the value be different if it is
evaluated at runtime e.g. &f.b - &f.a?
I cannot tell for C, but the corresponding expression is supposed to
raise a Constraint_Error exception in Ada (this is how all null pointer
deferences are supposed to behave).
--
Pierre-Marie de Rodat
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] About self-referencial sized types
Todd, On 05/27/2014 06:16 PM, Todd Allen wrote: Sorry for the last response on this. But perhaps an example from our Ada compiler will help you. Well, thank you very much for this! Anyway, the significant thing is that we're not referencing "n" directly, but rather the stored values for the upper bound. If you store the result of max(0,n) somewhere, you could reference it directly. For the case of general expression upper bounds, you'd have to store the values somewhere (freeze them) in case they might produce different results on subsequent evaluations. But I don't know if the max(0,n) might be a special case where you don't do that. That's interesting. Unfortunately, we do not store the value of the upper bounds in the record (nor anywhere else): the only way to get it at runtime is to compute it from the discriminants. The discriminants are the only runtime arguments that can determine the array bounds, so there is no risk that the bound expressions would produce different results sometimes. -- Pierre-Marie de Rodat ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
[Dwarf-Discuss] Regarding concrete inlined and out-of-line inlined instances
Hi, I have the below debug information (dwarf4) generated by the GCC compiler v4.8.2 for an inlined function. Please help me with the following query. In the concrete inlined instance of 'ext2_lookup', its DW_AT_entry_pc value (0xc01b49d0) is overlapping with the address range i.e. DW_AT_low_pc (0xc01b4980) and DW_AT_high_pc (0xc01b4a60) of the out-of-line instance root entry. Is this overlapping legitimate and how? <1><1038302>: Abbrev Number: 51 (DW_TAG_subprogram) <1038303> DW_AT_name: (indirect string, offset: 0x7a615): ext2_lookup <1038307> DW_AT_decl_file : 1 <1038308> DW_AT_decl_line : 58 <1038309> DW_AT_prototyped : 1 <103830a> DW_AT_type: <0x10330af> <103830e> DW_AT_inline : 1 (inlined) <103830f> DW_AT_sibling : <0x1038359> <2><1038313>: Abbrev Number: 52 (DW_TAG_formal_parameter) <1038314> DW_AT_name: dir <1038318> DW_AT_decl_file : 1 <1038319> DW_AT_decl_line : 58 <103831a> DW_AT_type: <0x103331d> <2><103831e>: Abbrev Number: 56 (DW_TAG_formal_parameter) <103831f> DW_AT_name: (indirect string, offset: 0x4fb14): dentry <1038323> DW_AT_decl_file : 1 <1038324> DW_AT_decl_line : 58 <1038325> DW_AT_type: <0x10330af> <2><1038329>: Abbrev Number: 56 (DW_TAG_formal_parameter) <103832a> DW_AT_name: (indirect string, offset: 0x1a72d5): flags <103832e> DW_AT_decl_file : 1 <103832f> DW_AT_decl_line : 58 <1038330> DW_AT_type: <0x1030083> <2><1038334>: Abbrev Number: 61 (DW_TAG_variable) <1038335> DW_AT_name: (indirect string, offset: 0x7a533): inode <1038339> DW_AT_decl_file : 1 <103833a> DW_AT_decl_line : 60 <103833b> DW_AT_type: <0x103331d> <2><103833f>: Abbrev Number: 57 (DW_TAG_variable) <1038340> DW_AT_name: ino <1038344> DW_AT_decl_file : 1 <1038345> DW_AT_decl_line : 61 <1038346> DW_AT_type: <0x1030243> <2><103834a>: Abbrev Number: 62 (DW_TAG_variable) <103834b> DW_AT_name: (indirect string, offset: 0xdd81): __func__ <103834f> DW_AT_type: <0x1038369> <1038353> DW_AT_artificial : 1 <1038354> DW_AT_const_value : (indirect string, offset: 0x7a615): ext2_lookup <1><1038359>: Abbrev Number: 8 (DW_TAG_array_type) <103835a> DW_AT_type: <0x1030168> <103835e> DW_AT_sibling : <0x1038369> <2><1038362>: Abbrev Number: 9 (DW_TAG_subrange_type) <1038363> DW_AT_type: <0x1030129> <1038367> DW_AT_upper_bound : 11 <1><1038369>: Abbrev Number: 11 (DW_TAG_const_type) <103836a> DW_AT_type: <0x1038359> .. ... . (some intermediate DIE entries) . <1><10397ce>: Abbrev Number: 92 (DW_TAG_subprogram) <10397cf> DW_AT_abstract_origin: <0x1038302> <10397d3> DW_AT_low_pc : 0xc01b4980 <10397db> DW_AT_high_pc : 0xc01b4a60 <10397e3> DW_AT_frame_base : 0x53243a(location list) <10397e7> DW_AT_GNU_all_call_sites: 1 <10397e8> DW_AT_sibling : <0x10398eb> <2><10397ec>: Abbrev Number: 70 (DW_TAG_formal_parameter) <10397ed> DW_AT_abstract_origin: <0x1038313> <10397f1> DW_AT_location: 0x5324c5(location list) <2><10397f5>: Abbrev Number: 70 (DW_TAG_formal_parameter) <10397f6> DW_AT_abstract_origin: <0x103831e> <10397fa> DW_AT_location: 0x53254d(location list) <2><10397fe>: Abbrev Number: 70 (DW_TAG_formal_parameter) <10397ff> DW_AT_abstract_origin: <0x1038329> <1039803> DW_AT_location: 0x5325e8(location list) <2><1039807>: Abbrev Number: 93 (DW_TAG_variable) <1039808> DW_AT_abstract_origin: <0x1038334> <2><103980c>: Abbrev Number: 93 (DW_TAG_variable) <103980d> DW_AT_abstract_origin: <0x103833f> <2><1039811>: Abbrev Number: 94 (DW_TAG_variable) <1039812> DW_AT_abstract_origin: <0x103834a> <1039816> DW_AT_location: 9 byte block: 3 c0 0 0 0 0 79 3e a0 (DW_OP_addr: c0793ea0) <2><1039820>: Abbrev Number: 95 (DW_TAG_inlined_subroutine) <1039821> DW_AT_abstract_origin: <0x1038302> <1039825> DW_AT_entry_pc: 0xc01b49d0 <103982d> DW_AT_ranges : 0x14a0c0 <1039831> DW_AT_call_file : 1 <1039832> DW_AT_call_line : 58 <3><1039833>: Abbrev Number: 96 (DW_TAG_formal_parameter) <1039834> DW_AT_abstract_origin: <0x103831e> <3><1039838>: Abbrev Number: 70 (DW_TAG_formal_parameter) <1039839> DW_AT_abstract_origin: <0x1038313> <103983d> DW_AT_location: 0x53264a(location list) <3><1039841>: Abbrev Number: 86 (DW_TAG_lexical_block) <1039842> DW_AT_ranges : 0x14a0f0 <4><1039846>: Abbrev Number: 87 (DW_TAG_variable) <1039847> DW_AT_abstract_origin: <0x1038334> <103984b> DW_AT_l
