search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.42k stars 12.15k forks source link

DW_AT_inline not present in assembly for an inlined inline function #12465

Open llvmbot opened 12 years ago

llvmbot commented 12 years ago
Bugzilla Link 12093
Version 3.0
OS Linux
Reporter LLVM Bugzilla Contributor
CC @dwblaikie,@echristo

Extended Description

Hello

I am trying to run following test case on Clang compiled output to compare the dwarf inline attributes in the resulting assembly output .

/ Inlined inline function must have abstract DIE / / { dg-do compile } / / { dg-options "-O2 -gdwarf-2 -dA -fpreprocessed" } / / { dg-final { scan-assembler "3.DW_AT_inline" } } */

​1 "test.h"

inline int t() { } int q() { t(); }

The testcase fails because, DW_AT_inline is not present in assembly output. Could anyone let me know why DW_AT_inline is not emitted with Clang compiled assembly output? I am aware that Clang uses C99 mode by default.

In case of GCC, .uleb128 0x2 @ (DIE (0x25) DW_TAG_subprogram) .byte 0x1 @ DW_AT_external .ascii "t\0" @ DW_AT_name .byte 0x1 @ DW_AT_decl_file (test.h) .byte 0x1 @ DW_AT_decl_line .4byte 0x30 @ DW_AT_type .byte 0x3 @ DW_AT_inline

In case of Clang, .byte 4 @ Abbrev [4] 0x87:0xa DW_TAG_subprogram .byte 116 @ DW_AT_name .byte 0 .byte 2 @ DW_AT_decl_file .byte 2 @ DW_AT_decl_line .long 128 @ DW_AT_type .byte 1 @ DW_AT_external .byte 0 @ End Of Children Mark

This appears to be a bug in LLVM ?

echristo commented 12 years ago

riddle me this: we inline a function completely (no vestiges of its instructions left), how do we know that we inlined it for debug info?

Hrm.

llvmbot commented 12 years ago

Hello,

I tried to debug this issue and found that the reason for failure is InlinedSubprogramDIEs.insert(OriginDIE); is not called.

After further debugging, found that ScopeDIE = constructInlinedScopeDIE(TheCU, Scope); is not being called because Scope->getInlinedAt()returns null.

if (Scope->getInlinedAt()) ScopeDIE = constructInlinedScopeDIE(TheCU, Scope);

On further inspection, it appears that handle values stored for inlined function is null and VP->HasValueHandle has 'false' value.

Could anyone give me some pointers on how it can be fixed ?

Note : When 'inline' is replaced with 'static' in the test code mentioned before, DW_AT_inline is emitted successfully for function 't'

static int t() { f(); }

llvmbot commented 1 year ago

@llvm/issue-subscribers-debuginfo

Author: None (llvmbot)

| | | | --- | --- | | Bugzilla Link | [12093](https://llvm.org/bz12093) | | Version | 3.0 | | OS | Linux | | Reporter | LLVM Bugzilla Contributor | | CC | @dwblaikie,@echristo | ## Extended Description Hello I am trying to run following test case on Clang compiled output to compare the dwarf inline attributes in the resulting assembly output . /* Inlined inline function must have abstract DIE */ /* { dg-do compile } */ /* { dg-options "-O2 -gdwarf-2 -dA -fpreprocessed" } */ /* { dg-final { scan-assembler "3.*DW_AT_inline" } } */ #​1 "test.h" inline int t() { } int q() { t(); } The testcase fails because, DW_AT_inline is not present in assembly output. Could anyone let me know why DW_AT_inline is not emitted with Clang compiled assembly output? I am aware that Clang uses C99 mode by default. In case of GCC, .uleb128 0x2 @ (DIE (0x25) DW_TAG_subprogram) .byte 0x1 @ DW_AT_external .ascii "t\0" @ DW_AT_name .byte 0x1 @ DW_AT_decl_file (test.h) .byte 0x1 @ DW_AT_decl_line .4byte 0x30 @ DW_AT_type .byte 0x3 @ DW_AT_inline In case of Clang, .byte 4 @ Abbrev [4] 0x87:0xa DW_TAG_subprogram .byte 116 @ DW_AT_name .byte 0 .byte 2 @ DW_AT_decl_file .byte 2 @ DW_AT_decl_line .long 128 @ DW_AT_type .byte 1 @ DW_AT_external .byte 0 @ End Of Children Mark This appears to be a bug in LLVM ?