RFC: DWARF debug tags for gfortran's OOP implementation

RFC: DWARF debug tags for gfortran's OOP implementation

[Tobias Burnus]

Dear all,

during the GCC Gathering I realized during the LTO debugging symbol 
discussion that gfortran does not generate debug information for the OOP 
features (cf. PR 49475).

The first issue to solve is which DWARF information one should generate. 
I have only very limited knowledge of DWARF, except that I quickly 
scanned "5.5.3 Derived or Extended Structs, Classes and Interfaces" and 
"5.5.7 Member Function Entries" (of http://www.dwarfstd.org/doc/DWARF4.pdf).

I think one should handle member functions (cf. example below). I am not 
sure whether other things like type extension or accessibility should be 
handled.

Tobias

! Example

module m
   implicit none

   type parent
     integer :: var_p = 3
   contains
     procedure, nopass :: memb => proc_parent
   end type parent
   ! Side note: nopass disables passing of the type itself ("this")
   ! Otherwise, the effective type would be passed as first argument to
   ! proc_parent

   type, extends(parent) :: child
   contains
     procedure, nopass :: memb => proc_child
   end type child

contains
   subroutine proc_parent()
      print *, "proc_parent"
   end subroutine proc_parent

   subroutine proc_child()
      print *, "proc_child"
   end subroutine proc_child
end module m

program main
   use m
   implicit none
   class(parent), allocatable :: a
   type(child) :: b

   allocate (parent :: a)
   call a%memb() ! Uses vtable to see that proc_parent should be called

   deallocate (a)
   allocate (child :: a)
   call a%memb() ! Uses vtable to see that proc_child should be called

   ! Variable access - resolved at compile time
   print *, b%var_p  ! Directly access "var_p"
   print *, b%parent%var_p ! Access it via the parent type
end program main

Re: RFC: DWARF debug tags for gfortran's OOP implementation

[Janus Weil]

Hi Tobias,

> during the GCC Gathering I realized during the LTO debugging symbol
> discussion that gfortran does not generate debug information for the OOP
> features (cf. PR 49475).

Btw, how was the London meeting? Anything interesting to report (Fortran-wise)?


> The first issue to solve is which DWARF information one should generate. I
> have only very limited knowledge of DWARF, except that I quickly scanned
> "5.5.3 Derived or Extended Structs, Classes and Interfaces" and "5.5.7
> Member Function Entries" (of http://www.dwarfstd.org/doc/DWARF4.pdf).
>
> I think one should handle member functions (cf. example below). I am not
> sure whether other things like type extension or accessibility should be
> handled.

Well, in principle all of those should be handled, I guess.

I don't have any experience with DWARF either, but maybe I'll look
into it, once I have gotten some of the more nasty OOP
bugs/regressions out of the way.

How would one tackle this practically? All the DWARF stuff is
generated in the middle-end, I assume (and probably the type
extension/member function info is already there for C++, right?). So,
the question is: What do we need to do in the front end, in order to
make the middle-end emit the right DWARF info?

Cheers,
Janus

Re: RFC: DWARF debug tags for gfortran's OOP implementation

[Tobias Burnus]

Hi Janus,

On 06/28/2011 02:12 PM, Janus Weil wrote:
> Btw, how was the London meeting? Anything interesting to report (Fortran-wise)?

General topics, cf. http://gcc.gnu.org/wiki/GCCGathering2011
Fortran wise:
- I met Paul and Thomas, we had some discussions - but the notes still 
have to be completed.
- We discussed with Richard the middle-end scalarizer (middle-end array 
expressions), which lead to the patches Richard has posted. (Fortran to 
do: Move more to that scalarizer, test it and remove then the Fortran 
scalarizer.)
- We found one module usage with rename debug issue (gdb bug, Jan has 
already posted [but not committed] a patch).
- (Thomas and I realized during the C vs. C++ discussion that Fortran - 
like C++ but contrary to C - allows a function result as lvalue. 
Fortran: A pointer-returning function call is a variable. Also other C++ 
0x problems or specialities sounded familiar - even if they show 
differences under the hood.)
- Array debug issue: As known, gdb cannot debug C99 VLA/Fortran-90-style 
arrays. (Jan has written a patch for Fedora in 2007, but that is not 
upstreamable.) Not discussed as the Diego immediately stopped it to move 
to another gdb item - thus there is no news about that one.
- Fortran OOP debug: Came into my mind in the debug streaming discussion 
related to freeing the lang-specific node vs. streaming of the debug info.

>> I think one should handle member functions (cf. example below). I am not
>> sure whether other things like type extension or accessibility should be
>> handled.
> Well, in principle all of those should be handled, I guess.

I have to admit that I am not 100% sure which make sense and match 
Fortran's semantic. I agree we should stream all debug tags which make 
sense to be streamed.

> How would one tackle this practically? All the DWARF stuff is
> generated in the middle-end, I assume

See gcc/dwarf2out.c - especially gen_type_die_for_member. This is called 
in gen_decl_die. I think in order to get this working, one also needs to 
use DECL_VINDEX (described in tree.h).

> (and probably the type extension/member function info is already there for C++, right?).

Yes, but one might still need middle end changes to accommodate for 
Fortran - the semantics of Fortran and C++ or Java are slightly different.


By the way, I can recomment elfutils's "eu-readelf -w" to dump the DWARF 
of object files and binaries. (You can also use binutil's "readelf", but 
that does not indent the output depending on the hierarchy and is thus 
less readable.)

Tobias

Re: RFC: DWARF debug tags for gfortran's OOP implementation

[Michael Eager]

On 06/27/2011 10:39 AM, Tobias Burnus wrote:
> Dear all,
>
> during the GCC Gathering I realized during the LTO debugging symbol discussion that gfortran does
> not generate debug information for the OOP features (cf. PR 49475).
>
> The first issue to solve is which DWARF information one should generate. I have only very limited
> knowledge of DWARF, except that I quickly scanned "5.5.3 Derived or Extended Structs, Classes and
> Interfaces" and "5.5.7 Member Function Entries" (of http://www.dwarfstd.org/doc/DWARF4.pdf).
>
> I think one should handle member functions (cf. example below). I am not sure whether other things
> like type extension or accessibility should be handled.

DWARF has attributes for accessibility (e.g., public, private).  If the
attributes are similar to those for C++, you should generate them in a
similar fashion.  I'm not sure what "type extension" means.  If there is
a comparable feature in C++ or other languages supported by DWARF, you
should generate similar DWARF info.  If these are different from any of
the supported languages, create a user attribute.  (And submit a proposal
at http://www.dwarfstd.org.)

You might translate the Fortran program into comparable C++ and
see what g++ generates, then try to match it with gfortran.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFC: DWARF debug tags for gfortran's OOP implementation

[Janus Weil]

>> I think one should handle member functions (cf. example below). I am not
>> sure whether other things
>> like type extension or accessibility should be handled.
>
> DWARF has attributes for accessibility (e.g., public, private).  If the
> attributes are similar to those for C++, you should generate them in a
> similar fashion.

I would say they are sufficiently similar in order to also use them for Fortran.


> I'm not sure what "type extension" means.

Well, this is just the Fortran terminology for what would be called
'inheritance' in C++.


> You might translate the Fortran program into comparable C++ and
> see what g++ generates, then try to match it with gfortran.

That might be a good starting point. Thanks for your comments.

Cheers,
Janus

Re: RFC: DWARF debug tags for gfortran's OOP implementation

[Tobias Burnus]

On 06/28/2011 04:21 PM, Michael Eager wrote:
> DWARF has attributes for accessibility (e.g., public, private). If the
> attributes are similar to those for C++, you should generate them in a
> similar fashion.

Well, Fortran has public and private - but I am not sure in how far it 
matches C++'s public and private (cf. also below).


 > I'm not sure what "type extension" means.

Type extension is inheritance, i.e. Fortran's

type parent
end type parent
type, extends(parent) :: child
end type child

matches C++'s

class parent {};
class child : public parent { };

 > If there is
> a comparable feature in C++ or other languages supported by DWARF, you
> should generate similar DWARF info.

I think that's to a certain extend my problem: I do not completely 
understand the current DWARF - nor the fine points of C++ to see in how 
far it matches.

For instance: While both in C++ and Fortran variables and methods can be 
public or private, Fortran just extends a type without having a concept 
of public/private/protected inheritance. The semantics of Fortran's 
public, private and protected is related to modules - which does not 
really match C++ concept. The DWARF spec does not really tell the 
implications of the accessibility tags, which makes it a tad more 
difficult to understand what should be done.

I think we will start by marking the VTABLE as such and to try to handle 
member functions. - And do compare how g++/gdb handle the approximate 
C++ version.

Tobias

Re: RFC: DWARF debug tags for gfortran's OOP implementation

[Tom Tromey]

>>>>> "Tobias" == Tobias Burnus <burnus@net-b.de> writes:

Tobias> The DWARF spec does not really tell the implications of the
Tobias> accessibility tags, which makes it a tad more difficult to
Tobias> understand what should be done.

That is ok -- the DWARF consumer will see that the CU is Fortran, and
will know to apply Fortran semantics.

Tom

Re: RFC: DWARF debug tags for gfortran's OOP implementation

[Michael Eager]

On 06/28/2011 11:36 AM, Tom Tromey wrote:
>>>>>> "Tobias" == Tobias Burnus<burnus@net-b.de>  writes:
>
> Tobias>  The DWARF spec does not really tell the implications of the
> Tobias>  accessibility tags, which makes it a tad more difficult to
> Tobias>  understand what should be done.
>
> That is ok -- the DWARF consumer will see that the CU is Fortran, and
> will know to apply Fortran semantics.

Yes.  DWARF attributes have to be interpreted in the context of
the language they are describing.

DWARF describes the source language constructs and how they are translated
into object files, while generally avoiding defining precise semantics for
each attribute.  Since each language has slightly different semantics for
shared concepts like accessibility, if DWARF did define precise semantics,
it would have to define a different attribute for each language or minor
variation.  Worse, we might end up in the awkward position of a language
standard being revised so that the DWARF definition no longer matched.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077