[cfe-dev] Debug info scope of explicit casting type does not seem correct

[David Blaikie via cfe-dev]

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160430/621d4f8e/attachment.html>