Bug 166921 - missing location attribute for static variable in inline
missing location attribute for static variable in inline
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-27 16:12 EDT by Roland McGrath
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-06 06:40:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
trivial test case (113 bytes, text/plain)
2005-08-27 16:12 EDT, Roland McGrath
no flags Details

  None (edit)
Description Roland McGrath 2005-08-27 16:12:50 EDT
Description of problem:

The DWARF info emitted for the test case omits location information for the
variable "now".  This is a static variable defined in an inline.

Version-Release number of selected component (if applicable):
gcc-4.0.1-4.fc4

How reproducible:
100%

Steps to Reproduce:
1.gcc -O -g -c inl2-test.c
2.eu-readelf --debug-dump=info inl2-test.o
3.look for "location" and don't find one associated with "now" or with its
concrete inlined instance entry in the concrete inlined instance tree inside "foo".
  
Actual results:
 [    36]      variable
               name                 "now"
               decl_file            1
               decl_line            3
               type                 [    42]
...
 [    6c]      inlined_subroutine
               abstract_origin      [    25]
               low_pc               0x00000003
               high_pc              0x00000012
 [    79]        lexical_block
                 low_pc               0x00000003
                 high_pc              0x00000012
 [    82]          variable
                   abstract_origin      [    36]



Expected results:

Either 36 or 82 ought to have a location attribute.
I wonder, can 82 be omitted entirely according to the spec?
It's not entirely clear to me.

Additional info:
Comment 1 Roland McGrath 2005-08-27 16:12:50 EDT
Created attachment 118190 [details]
trivial test case
Comment 2 Jakub Jelinek 2005-09-01 03:56:18 EDT
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.
Comment 3 Roland McGrath 2005-09-02 00:45:10 EDT
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.
Comment 4 Jakub Jelinek 2005-09-02 05:36:32 EDT
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.
Comment 5 Roland McGrath 2005-09-02 05:47:13 EDT
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.
Comment 6 Jakub Jelinek 2005-09-06 06:40:24 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.