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

George Helffrich george@geology.bristol.ac.uk
Thu Dec 6 07:17:00 GMT 2007


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.



More information about the Gcc-patches mailing list