[PING][PATCH,DWARF,gfortran] Change DWARF-2 output for Fortran COMMON symbols
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
>>> I don't see the discussion there nor do I understand what STABS has
>>> to do with DWARF in this context.
>>>> 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
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?
More information about the Gcc-patches