Bug 166921
Summary: | missing location attribute for static variable in inline | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Roland McGrath <roland> | ||||
Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||
Status: | CLOSED UPSTREAM | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 4 | CC: | rth | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-09-06 10:40:24 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Roland McGrath
2005-08-27 20:12:50 UTC
Created attachment 118190 [details]
trivial test case
It varries between C and C++. For: static inline int stamp (void) { static int now; return ++now; } int foo (int x) { return x * stamp (); } int bar (int x) { return x * stamp (); } int baz (int x) { return x * stamp (); } and between 4.0.x and 4.1: 4.0 gcc -S -O2 -g -dA: .uleb128 0x3 # (DIE (0x3a) DW_TAG_variable) .ascii "now\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file .byte 0x3 # DW_AT_decl_line .long 0x46 # DW_AT_type in "stamp", i.e. DW_AT_inline, then: .uleb128 0x9 # (DIE (0xa2) DW_TAG_variable) .long 0x3a # DW_AT_abstract_origin only in baz and: .uleb128 0xa # (DIE (0xff) DW_TAG_variable) .long 0x3a # DW_AT_abstract_origin .byte 0x9 # DW_AT_location .byte 0x3 # DW_OP_addr .quad now.1498 in foo and bar (baz being the first DW_TAG_subprogram emitted into the debug info). When compiled with 4.0.x g++ -S -g -O2 -dA, I get: .uleb128 0x4 # (DIE (0x3a) DW_TAG_variable) .ascii "now\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file .byte 0x3 # DW_AT_decl_line .long 0x47 # DW_AT_type in stamp, then .uleb128 0x8 # (DIE (0x7b) DW_TAG_variable) .long 0x3a # DW_AT_abstract_origin .byte 0x9 # DW_AT_location .byte 0x3 # DW_OP_addr .quad _ZZ5stampvE3now for the comdat copy of stamp and: .uleb128 0xc # (DIE (0xe4) DW_TAG_variable) .long 0x3a # DW_AT_abstract_origin only in foo, bar and baz. In HEAD gcc -S -g -O2 -dA, I get: .uleb128 0x3 # (DIE (0x3a) DW_TAG_variable) .ascii "now\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file .byte 0x3 # DW_AT_decl_line .long 0x50 # DW_AT_type .byte 0x9 # DW_AT_location .byte 0x3 # DW_OP_addr .quad now.1610 in stamp (the DW_AT_inline subprogram) and no DW_TAG_variable for it in either foo, bar or baz. With HEAD g++ -S -g -O2 -dA I get: .uleb128 0x4 # (DIE (0x3a) DW_TAG_variable) .byte 0x9 # DW_AT_location .byte 0x3 # DW_OP_addr .quad _ZZ5stampvE3now in DW_AT_inline stamp and no DW_TAG_variable in foo, bar nor baz. Now, I think we should first decide what's the correct output and then fix the compilers to match it. To me HEAD gcc output looks the most correct, although I'm not sure if the DW_TAG_variables in the routines into which it has been inlined can be omitted. HEAD g++ is certainly not correct, it doesn't emit DW_AT_name, DW_AT_decl_{file,line} nor DW_AT_type for the variable anywhere. If it is clear what is the desired output, I'll take care of finding the HEAD changes and/or trying to debug HEAD bugs. The HEAD output shown is correct AFAICT. The spec allows omitting child DIEs of DW_TAG_inlined_subroutine if they have no information but DW_AT_abstract_origin; they are implied by the DW_AT_abstract_origin of the parent DIE. This has been fixed on HEAD with http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00871.html but as various parts this patch relies on changed a lot, it might not be very easy to backport. How urgently we need this fixed? If FC5/RHEL5 timeframe would be enough, we could just fix the C++ bug on HEAD with the above testcase and put in testcases to make sure this keeps working until 4.1 release. I just noticed the bug by eyeball, it isn't blocking anything in particular. It may become an issue for systemtap, if there turns out to be such a case for a variable someone needs to fetch. But that demand would depend on a specific case coming up and the tapwriter really caring about the particular unreachable variable. If it were to become pressing, it might be wanted for RHEL4 (3.4) as well. There is no special reason to preemptively presume it's important. Fix for HEAD is http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00103.html Closing as UPSTREAM, if we'll need to backport this, please reopen. |