Re: [PING][PATCH,DWARF,gfortran] Change DWARF-2 output for Fortran COMMON symbols

[George Helffrich <george at geology dot bristol dot ac dot uk>]

On 5 Dec 2007, at 18:20, Geoff Keating wrote:

> On Dec 5, 2007, at 1:29 AM, George Helffrich 
> <george@geology.bristol.ac.uk> wrote:
>
> > On 27 Nov 2007, at 20:04, Geoff Keating wrote:
> >
> > > On 27/11/2007, at 3:14 AM, George Helffrich wrote:
> > >
> > > > On 27 Nov 2007, at 08:45, Geoff Keating wrote:
> > > >
> > > > > On 26/11/2007, at 8:50 PM, George Helffrich wrote:
> > > > >
> > > > > > A similar problem arises with .stabs debug information -- for the 
> > > > > > long answer, please see the discussion linked from
> > > > > >
> > > > > > http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02475.html
> > > > >
> > > > > I don't see the discussion there nor do I understand what STABS 
> > > > > has to do with DWARF in this context.
> > > >
> > > > OK
> > > >
> > > > > > Briefly, it not possible to fix this in GDB.  The problem lies in 
> > > > > > Darwin loader, which refuses to relocate
> > > > >
> > > > > Neither the Darwin linker nor the Darwin loader participates in 
> > > > > DWARF in any way.
> > > >
> > > > I guess this depends on what you call a lookup system for symbols 
> > > > in a loaded program.  Apple GDB processes DWARF by querying the 
> > > > locations of symbols based on text strings in the .o files.  To me 
> > > > this sounds like a linker- or loader-related function, but 
> > > > terminology may vary.
> > >
> > > Well, OK, but 'querying the locations of symbols' does not include
> > >
> > > > > > references like SYM+offset in non .text sections
> > >
> > > instead you query for SYM and then add offset to the result.
> > >
> > > > > > -- a design decision unlikely to be changed by Apple.  To 
> > > > > > relocate symbols in .comm, Apple's GDB for Darwin gets around 
> > > > > > this restriction by assuming that every DWARF symbol reference is 
> > > > > > either 1) a symbol whose name is the name of the .comm section; 
> > > > > > otherwise 2) an offset into the .text section.
> > > > >
> > > > > What GDB should do is read the actual relocs out of the .o files 
> > > > > and interpret those, rather than making assumptions that prove to 
> > > > > be incorrect.  Alternatively, its assumptions should be improved.
> > > >
> > > > This approach is feasible provided the loader retains enough 
> > > > context to interpret raw relocation information *after* a program 
> > > > is loaded.
> > >
> > > Obviously there is 'enough context' otherwise loading plugins would 
> > > not work.  I don't understand why you think the loader should do 
> > > this.  GDB should do it.
> >
> > This is not so obvious to me.  There is difference between looking up 
> > symbols in a load map and retaining sufficiently detailed information 
> > to parse raw relocation entries in object files.
> >
> > > > I don't know if the Darwin loader/linker does.  What I do know is 
> > > > that non-Apple GDB works with the proposed patch, and Apple's GDB 
> > > > can work with this DWARF hint.  A lobbying effort to significantly 
> > > > change Apple GDB seems an unreliable route to achieving proper 
> > > > Fortran debug support.  (But I guess I could be missing a 
> > > > consulting opportunity.)
> > >
> > > Didn't you already say that you needed to change GDB to make Fortran 
> > > debugging work properly?
> >
> > Only Apple GDB, and with DWARF, but not with stabs.
> >
> > -----
> >
> > To clearly state the benefits to Fortran:
> >
> > 1) It uses a DWARF facility expressly created for Fortran;
> >
> > 2) It uses DWARF like other Fortran compilers do (Intel's ifort);
> >
> > 3) It does not affect anything other than Fortran;
> >
> > 4) It provides a route to debug support on all platforms including 
> > Darwin.
> >
> > I'm quite puzzled at the resistance here; the motivation is not 
> > frivolous, but satisfies a real need; perhaps other gfortran opinions 
> > should be heard?
>
> I am not objecting to the patch in principle, only to the parts of it 
> which are workarounds to GDB bugs, or which are otherwise wrong.  
> Indeed I think a patch would be much simpler if it was more directed 
> at the benefits above and not at workarounds.

I'm glad that you clarified this, thanks.  It shows that there is a 
misunderstanding of the patch.

The patch only changes gfortran's debug information under DWARF to use 
DW_TAG_common_block to describe identifiers located in Fortran common.  
The implementation follows DWARF-2 documentation of this facility.  No 
part of the code is specifically a workaround.  If there are any 
objectionable parts, I will explain and/or change as required.