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

George Helffrich george@geology.bristol.ac.uk
Wed Dec 5 09:29:00 GMT 2007


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?

                                                                         
      George Helffrich



More information about the Gcc-patches mailing list