thr3ads.net - llvm dev - [llvm-dev] Debug info scope of explicit casting type does not seem correct [May 2016]

If this information is useful, please help other people find it:
Share via:

Aboud, Amjad via llvm-dev

2016-May-07 10:02 UTC

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

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<mailto: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.cppclass 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/llvm-dev/attachments/20160507/15cd783d/attachment-0001.html>

David Blaikie via llvm-dev

2016-May-07 18:38 UTC

head link

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

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/llvm-dev/attachments/20160507/60e2b280/attachment.html>

Aboud, Amjad via llvm-dev

2016-May-08 08:13 UTC

head link

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

That happens because we create the subprogram below as a context to the
“DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was
added to the retained type list because of the explicit cast to (T*).

This is the code that creates DW_TAG_subprogram:

DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) {

...

  // DW_TAG_inlined_subroutine may refer to this DIE.
  DIE &SPDie = createAndAddDIE(dwarf::DW_TAG_subprogram, *ContextDIE, SP);

  // Stop here and fill this in later, depending on whether or not this
  // subprogram turns out to have inlined instances or not.
  if (SP->isDefinition())
    return &SPDie;                                <-------------  In our
case the function returns here, and does not apply attributes.

  applySubprogramAttributes(SP, SPDie);
  return &SPDie;
}

It assumes that later when the function is finalized the attributes will be
applied, which is called from this code:

void DwarfDebug::finishSubprogramDefinitions() {
  for (auto &F : MMI->getModule()->functions())
    if (auto *SP = F.getSubprogram())
      if (ProcessedSPNodes.count(SP) &&
          SP->getUnit()->getEmissionKind() != DICompileUnit::NoDebug)
        forBothCUs(*CUMap.lookup(SP->getUnit()), [&](DwarfCompileUnit
&CU) {
          CU.finishSubprogramDefinition(SP);          <-------------  In our
case, this code will not be reached for the above subprogram.
        });
...
}

However, the function was optimized out and the code will not call
“finishSubprogramDefinition” for it, and attributes will not be added.

Regards,
Amjad


From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Saturday, May 07, 2016 21:38
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

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<mailto: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<mailto:dblaikie at
gmail.com>]
Sent: Saturday, April 30, 2016 17:59
To: Aboud, Amjad <amjad.aboud at intel.com<mailto:amjad.aboud at
intel.com>>
Cc: Adrian Prantl <aprantl at apple.com<mailto:aprantl at
apple.com>>; llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>>; Clang Dev <cfe-dev at
lists.llvm.org<mailto: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<mailto: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.cppclass 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.

---------------------------------------------------------------------
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/llvm-dev/attachments/20160508/bf5fcfd4/attachment.html>

Possibly Parallel Threads

Search for more apparently analagous threads

llvm dev - May 2016 - Debug info scope of explicit casting type does not seem correct

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

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

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

Possibly Parallel Threads