Bug 586683 - useless DW_AT_frame_base generated
useless DW_AT_frame_base generated
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
13
All Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-28 03:11 EDT by Roland McGrath
Modified: 2011-06-27 11:55 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 11:55:25 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)
WIP patch (3.95 KB, patch)
2010-04-30 12:19 EDT, Jakub Jelinek
no flags Details | Diff

  None (edit)
Description Roland McGrath 2010-04-28 03:11:45 EDT
Description of problem:

The DW_AT_frame_base attribute has no purpose or meaning unless an owned DIE has DW_AT_static_link or refers to a DWARF expression (including location list entries) that uses DW_OP_fbreg.  GCC always emits one anyway.  It would save space to omit it when nothing refers to it.

Version-Release number of selected component (if applicable):
4.4.3-18.fc13

How reproducible:


Steps to Reproduce:
1.echo 'void foo () {}' | gcc -g -O99 -o - -S -xc - -dA | grep frame_base
2.
3.
  
Actual results:

Has a DW_AT_frame_base.

Expected results:

Needs none.

Additional info:
Comment 1 Jakub Jelinek 2010-04-30 12:19:56 EDT
Created attachment 410533 [details]
WIP patch

Patch, which unfortunately doesn't bootstrap.

The problem is that at least for Fortran and Ada we apparently sometimes emit
variable length array type DIEs e.g. for function parameters at DW_TAG_compile_unit scope.  And the location descriptions of those types (such as DW_AT_string_length or DW_AT_upper_bound etc.) sometimes use DW_OP_fbreg.

Is that valid DWARF?  If yes, the patch to optimize out DW_AT_frame_base would be more expensive thing (it would basically need to in addition to just walking
the children also need to walk references (all, or just some - which ones?) from the children to DIEs that aren't children of this DW_TAG_subprogram or DW_TAG_entry_point.  What if DW_OP_fbreg appears in children of the DW_TAG_subprogram referenced through DW_AT_abstract_origin of the DW_TAG_subprogram for which it is applied.  Etc.
Comment 2 Roland McGrath 2010-04-30 17:22:33 EDT
I'm not entirely clear on what an example of the Fortran/ADA cases looks like.  Any use of DW_OP_fbreg in a DIE that is not owned by a DW_TAG_subprogram seems like it must be wrong and not have any well-defined meaning.

As to the inline case, I'd have to consider the particular use.  Off hand it seems like it would be valid and well-defined enough.  The abstract inlined definition can supply whatever locations would make sense if they appeared directly in all of the concrete inlined instances that do not override that corresponding DIE.
Comment 3 Jakub Jelinek 2010-05-03 09:23:30 EDT
Consider:
function foo (x)
  character (kind=1,len=*) :: x
  integer (kind=4) :: foo
  foo = len (x)
end function

gfortran -c -g -O2 -dA foo.f90
eu-readelf -w foo.o

 Version: 2, Abbreviation section offset: 0, Address size: 4, Offset size: 4
 [     b]  compile_unit
           producer             "GNU Fortran 4.4.3 20100127 (Red Hat 4.4.3-4)"
           language             Fortran95 (14)
           name                 "/tmp/foo.f90"
           low_pc               .text+0000000000 <foo_>
           high_pc              .bss+0000000000
           stmt_list            0
 [    21]    subprogram
             external             Yes
             name                 "foo"
             decl_file            1
             decl_line            1
             type                 [    5f]
             low_pc               .text+0000000000 <foo_>
             high_pc              .bss+0000000000
             frame_base                         [   0] call_frame_cfa
             sibling              [    5f]
 [    3b]      formal_parameter
               name                 "x"
               decl_file            1
               decl_line            1
               type                 [    66]
               location                             [   0] fbreg 0
                [   2] deref
 [    48]      formal_parameter
               name                 "_x"
               type                 [    6a]
               artificial           Yes
               location                             [   0] fbreg 4
 [    54]      variable
               name                 "__result_foo"
               type                 [    5f]
               artificial           Yes
 [    5f]    base_type
             byte_size            4
             encoding             signed (5)
             name                 "integer(kind=4)"
 [    66]    string_type
             string_length                      [   0] fbreg 4
 [    6a]    const_type
             type                 [    5f]

DIE 66 is not a child of DIE 21, makes any sense only when used from within that function.  Are you saying this is invalid and the type must be owned by DIE 21?

For the abstract origin case, I believe GCC currently doesn't anything like that, the only case which will have location expressions in the abstract origin are likely static vars in inline functions or ctors/dtors.
Comment 4 Roland McGrath 2010-05-03 14:15:32 EDT
I see.  For an anonymous type, I'm not sure what meaning there is to where it appears in the scope tree, one way or the other.  Having top-level anonymous types is already normal, and makes it more sensible to have two such functions share the same type DIE when it happens to be identical.  So the evaluation of any type (potentially) has to consider some "current frame" as reference.
Comment 5 Bug Zapper 2011-06-02 10:46:55 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Bug Zapper 2011-06-27 11:55:25 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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