[Bug debug/53453] New: darwin linker expects both AT_name and AT_comp_dir debug notes

["howarth at nitro dot med.uc.edu" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53453

             Bug #: 53453
           Summary: darwin linker expects both AT_name and AT_comp_dir
                    debug notes
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


Future versions of dsymutil on darwin will emit warnings of the form...

warning: no debug symbols in executable (-arch x86_64)

warning: no debug symbols in executable (-arch i386)

when the debug note for AT_comp_dir is missing from linked object files.
Upstream had the following comments...

------------------------------------------------------------------------
The issue is not directly dsymutil.  The way it works on darwin, is that 
the linker does not copy dwarf debug info.  Instead, the linker leaves 
the debug info in the .o files and then puts "debug notes" into the final 
linked image. If you run the program under gdb, the debugger sees the 
notes and opens the .of files and reads the dwarf. If instead you run 
dysmtuil, it reads the debug notes which tells it where to find the 
.o files from which to read the dwarf and merge all the dwarf into 
the .dSYM.

The dsymtuil warning is that no dwarf was found.  In this case that 
is because there were no debug notes recorded by the linker which 
was because of the lack of AT_comp_dir.   In some of the cases you've 
set up, there was no warning because there was some dwarf found but 
not all dwarf was found, so the .dSYM is less than ideal.

The format of the debug notes requires a pair of dir/file.  Because 
it always just worked before, the linker just copied the dir from 
AT_comp_dir and the file from AT_name. It does not look like the 
dwarf spec requires the AT_comp_dir, but it has always been there 
before and the linker has come to depend on it.
-------------------------------------------------------------------------

This issue can be demonstrated with Xcode 4.2 under 10.7.4 using gcc trunk...


howarth% gcc-fsf-4.8
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120520/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120520/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c
/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120520/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
-fno-diagnostics-show-caret --save-temps -w -O3 -g -lm -m64 -o 20010124-1.x4
howarth% dwarfdump --debug-info main.o | grep -A3 AT_language
             AT_language( DW_LANG_C89 )
             AT_name(
"/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120520/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c"
)
             AT_stmt_list( 0x00000000 )

whereas if you copy or symlink the source files into a local directory and
compile with...

howarth% gcc-fsf-4.8 20010124-1.c 20010124-1-lib.c main.c
-fno-diagnostics-show-caret --save-temps -w -O3 -g -lm -m64 -o 20010124-1.x4

...both the AT_name and AT_comp_dir debug notes are present...

howarth% dwarfdump --debug-info main.o | grep -A3 AT_language                  
                               AT_language( DW_LANG_C89 )
             AT_name( "main.c" )
             AT_comp_dir( "/Users/howarth/xcode44_bugv2/good_binary" )
             AT_stmt_list( 0x00000000 )

and future dsymutil releases won't emit the warning.