Bug 586683

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.

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.

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.

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.

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

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.