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

[Geoff Keating]

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.