Debug info scope of explicit casting type does not seem correct

Project Infrastructure LLVM Dev List Archives
1

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

int foo(void* in) {

typedef typename X::type T;

const T* p = (T*) in;

return p->x;

}

int bar() {

A a;

return foo(&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”, 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

2

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@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@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))
3

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

4

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.

5

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

6

That’d be a bug - we should finish adding attributes to it at some point. If we can detect that it’s never going to be handled (that it’s been entirely optimized away) by the other codepaths, we should do it up-front. Otherwise we may need to add it to a list somewhere to be handled.

Ah, this probably regressed when we switched the direction of the link in subprograms (from CU->subprogram to subprogram->CU). Adrian?

7

Hi,

As we are talking about the code Adrian added, there is another issue with this code that leads into adding “DW_AT_abstract_origin” twice in the case when we have an inline function that is emitted also as concrete function.

Source (test.cpp):

int bar(int x) {

return x+9;

}

int foo(int y) {

return bar(y);

}

Command line:

clang “-cc1” “-triple” “x86_64-linux” “-emit-obj” “-debug-info-kind=standalone” “-O2” test.cpp “-o -” | llvm-dwarfdump -debug-dump=info –

0x0000002a: DW_TAG_subprogram [2] *

DW_AT_low_pc [DW_FORM_addr] (0x0000000000000000)

DW_AT_high_pc [DW_FORM_data4] (0x00000004)

DW_AT_APPLE_omit_frame_ptr [DW_FORM_flag_present] (true)

DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 57 )

DW_AT_abstract_origin [DW_FORM_ref4] (cu + 0x004b => {0x0000004b} “_Z3bari”)

DW_AT_abstract_origin [DW_FORM_ref4] (cu + 0x004b => {0x0000004b} “_Z3bari”)

This also happen due to “finishSubprogramDefinitions”:

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); <------------- This line adds the first DW_AT_abstract_origin

});

for (auto *AbsScope : LScopes.getAbstractScopesList())

if (auto *SP = dyn_cast(AbsScope->getScopeNode()))

if (ProcessedSPNodes.count(SP) &&

SP->getUnit()->getEmissionKind() != DICompileUnit::NoDebug)

forBothCUs(*CUMap.lookup(SP->getUnit()), [&](DwarfCompileUnit &CU) {

CU.finishSubprogramDefinition(SP); <------------- This line adds the second DW_AT_abstract_origin

});

}

Regards,

Amjad

8

Hi,
As we are talking about the code Adrian added, there is another issue with this code that leads into adding “DW_AT_abstract_origin” twice in the case when we have an inline function that is emitted also as concrete function.

Thanks for catching this:

Prevent DW_AT_abstract_origin from being emitted twice for the same subprogram
http://reviews.llvm.org/D20072

-- adrian