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

George Helffrich george@geology.bristol.ac.uk
Tue Nov 27 13:47:00 GMT 2007


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,
>
> 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.

>
>> which refuses to relocate references like SYM+offset in non .text 
>> sections -- 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.  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.)

                                                                         
      George Helffrich



More information about the Gcc-patches mailing list