From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============2306406594333376047==" MIME-Version: 1.0 From: Conrad Rad To: elfutils-devel@lists.fedorahosted.org Subject: Re: dwarf_aggregate_size() seems to fall over on pointer types Date: Wed, 01 Oct 2014 14:34:10 -0400 Message-ID: In-Reply-To: 542C3E0C.3000503@redhat.com --===============2306406594333376047== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, Oct 1, 2014 at 1:46 PM, Josh Stone wrote: > On 10/01/2014 10:15 AM, Conrad Rad wrote: >> I've compiled a small example program, repro, and output[2]: >> http://pastie.org/9610702 >> >> dwarf_aggregate_size() has no trouble with most member types, or even >> pointer types on the output from GCC. However, it returns an error on >> Clang's output. >> >> Perhaps Clang is just eliding pointer size information, assuming >> consumers will consult the Elf machine class and infer? > > Indeed, clang doesn't seem to output DW_AT_byte_size on any > DW_TAG_pointer_type, but gcc does. > > FWIW, the DWARF4 Appendix A does *not* list DW_AT_byte_size as being > applicable to DW_TAG_pointer_type, nor DW_TAG_reference_type, nor > DW_TAG_rvalue_reference_type. However, that is just "informative", and > producers are free to omit some of the suggestions as well as add their > own, so it's not an error that gcc produces DW_AT_byte_size. > >> Am I missing something? Is this a Clang bug or an elfutils bug? > > I don't think it's strictly a bug in either. Clang is not required to > produce byte_size, and elfutils is just reporting what it knows. > > Still, it might be nice if elfutils made that machine-class inference > for you. (But I worry about things like that mips pointer issue > reported recently.) It'd be nice. If it's just pointers and arrays of pointers, I can cobble a fallback together. Members that have struct types with pointer members should get their own size information emitted by both compilers, I guess? (Both generate size information for 'struct b'.) What was the issue with MIPS pointers, by the way? Thanks, Conrad --===============2306406594333376047==--