[cfe-dev] Debug info scope of explicit casting type does not seem correct
David Blaikie via cfe-dev
cfe-dev at lists.llvm.org
Sat May 7 11:38:01 PDT 2016
Under what conditions do we produce a subprogram with no attributes? At
first glance that certainly seems not useful, but perhaps there's a reason
for it.
On Sat, May 7, 2016 at 3:02 AM, Aboud, Amjad <amjad.aboud at intel.com> wrote:
> Hi David,
>
> OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram
> scope.
>
> But how about that we are emitting a subprogram entry that has no
> attributes?
>
>
>
> 0x0000002b: DW_TAG_subprogram [3] *
>
>
>
> 0x0000002c: DW_TAG_typedef [4]
>
> DW_AT_type [DW_FORM_ref4] (cu + 0x0040
> => {0x00000040})
>
> DW_AT_name [DW_FORM_strp] (
> .debug_str[0x00000060] = "T")
>
> DW_AT_decl_file [DW_FORM_data1]
> ("c:\temp\ICL\LB\retain.cpp")
>
> DW_AT_decl_line [DW_FORM_data1] (16)
>
>
>
>
>
> Regards,
>
> Amjad
>
> *From:* David Blaikie [mailto:dblaikie at gmail.com]
> *Sent:* Saturday, April 30, 2016 17:59
> *To:* Aboud, Amjad <amjad.aboud at intel.com>
> *Cc:* Adrian Prantl <aprantl at apple.com>; llvm-dev <llvm-dev at lists.llvm.org>;
> Clang Dev <cfe-dev at lists.llvm.org>
> *Subject:* Re: Debug info scope of explicit casting type does not seem
> correct
>
>
>
> Yep, seems fine/reasonable to me. The pointer type has no logical scope so
> it doesn't really matter where its DIE goes.
>
> GCC does put the pointer type in the function scope in basic cases, but it
> can also end up in other places. For example:
>
> blaikie at blaikie-linux:~/dev$ cat func.cpp
>
> void sink(void*);
>
> template<typename T>
>
> void f1() {
>
> T *t;
>
> sink(&t);
>
> }
>
> void f2() {
>
> struct foo { };
>
> f1<foo>();
>
> }
>
> blaikie at blaikie-linux:~/dev$ g++-4.7 -std=c++11 func.cpp -g -c && llvm-dwarfdump-tot -debug-dump=info func.o | grep DW_TAG
>
> 0x0000000b: DW_TAG_compile_unit [1] *
>
> 0x0000002d: DW_TAG_subprogram [2] * // f2
>
> 0x00000051: DW_TAG_lexical_block [3]
>
> 0x00000062: DW_TAG_structure_type [4]
>
> 0x0000006b: DW_TAG_subprogram [5] * // f1
>
> 0x00000087: DW_TAG_template_type_parameter [6]
>
> 0x0000008e: DW_TAG_lexical_block [7] *
>
> 0x0000009f: DW_TAG_variable [8]
>
> 0x000000ab: DW_TAG_pointer_type [9] // foo*
>
>
>
> & in fact, if you introduce another template that's similar to f1, its variable's type is 0x00ab - so it points into f1's children. Seems GCC puts it in whatever scope first references the pointer type.
>
>
>
> I think it's probably as sensible, and a bit simpler, to put any such basic types in the CU scope.
>
>
>
> (granted, if GCC and Clang were really smart, the pointer type in f1 could be pointer to 0x0087 - but that would really bloat the debug info (now every different way of writing foo* in every different template would be a separate type description... - that would probably be not good))
>
>
>
> On Sat, Apr 30, 2016 at 3:32 AM, Aboud, Amjad <amjad.aboud at intel.com>
> wrote:
>
> Hi,
>
> I am wondering if this behavior of creating debug info is correct.
>
> A type in compile unit entry is pointing to a type under subprogram entry?!
>
>
>
> This is the root cause of https://llvm.org/bugs/show_bug.cgi?id=27579
>
>
>
> 0x0000000b: DW_TAG_compile_unit [1] *
>
>
>
> 0x00000026: DW_TAG_pointer_type [2]
>
> DW_AT_type [DW_FORM_ref4] (cu + 0x002c
> => {0x0000002c})
>
>
>
> 0x0000002b: DW_TAG_subprogram [3] *
>
>
>
> 0x0000002c: DW_TAG_typedef [4]
>
> DW_AT_type [DW_FORM_ref4] (cu + 0x0040
> => {0x00000040})
>
> DW_AT_name [DW_FORM_strp] (
> .debug_str[0x00000060] = "T")
>
> DW_AT_decl_file [DW_FORM_data1]
> ("c:\temp\ICL\LB\retain.cpp")
>
> DW_AT_decl_line [DW_FORM_data1] (16)
>
>
>
> 0x00000037: NULL
>
>
>
>
>
> command line:
>
> clang -cc1 -triple i386-apple-ios9.0.0 -emit-obj -debug-info-kind=limited
> -O2 test.cpp –o - | llvm-dwarfdump -debug-dump=info -
>
>
>
> > cat test.cpp
>
> class A {
>
> public:
>
> int x;
>
> };
>
>
>
>
>
> class B {
>
> public:
>
> typedef A type;
>
> };
>
>
>
> template<typename X>
>
> int foo(void* in) {
>
> typedef typename X::type T;
>
> const T* p = (T*) in;
>
> return p->x;
>
> }
>
>
>
> int bar() {
>
> A a;
>
> return foo<B>(&a);
>
> }
>
>
>
> Reason for this behavior is the explicit cast “(T*)“, which leads into the
> following IR:
>
>
>
> !0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1,
> producer: "clang version 3.9.0 (trunk 267335)", isOptimized: true,
> runtimeVersion: 0, emissionKind: FullDebug, enums: !2, retainedTypes: !3)
>
> !3 = !{!4}
>
> !4 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !5, size: 32,
> align: 32) <----------------- No Scope, leads to compile unit scope!!
>
> !5 = !DIDerivedType(tag: DW_TAG_typedef, name: "T", scope: !7, file: !6,
> line: 16, baseType: !20)
>
> !7 = distinct !DISubprogram(name: "foo<B>", linkageName: "_Z3fooI1BEiPv",
> scope: !6, file: !6, line: 15, type: !8, isLocal: false, isDefinition:
> true, scopeLine: 15, flags: DIFlagPrototyped, isOptimized: true, unit: !0,
> templateParams: !12, variables: !15)
>
>
>
>
>
> Thanks,
>
> Amjad
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160507/60e2b280/attachment.html>
More information about the cfe-dev
mailing list