This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]