[Bug debug/46749] New: gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[Bug debug/46749] New: gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

           Summary: gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures
                    on darwin
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


The new gcc.dg/debug/pr41893-1.c testcase fails on darwin as...

FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -O (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -O3 (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O3 (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O (test for excess errors)
FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O3 (test for excess errors)

where the form of the failure is...

/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101201/gcc/testsuite/gcc.dg/debug/pr41893-1.c
-gdwarf-2 -g1 -flto -fwhole-program -O
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20101201/gcc/testsuite/gcc.dg/debug/pr41893-2.c
-lm -m32 -o pr41893-1.exe
warning: (i386) /var/tmp//cchADStB.ltrans0.ltrans.o unable to open object file
warning: no debug symbols in executable (-arch i386)

>From the output with -v this appears to be a dsymutil related issue...

 /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/as -arch i386
-force_cpusubtype_ALL -o /var/tmp//ccyf23lE.ltrans0.ltrans.o
/var/tmp//ccJ7sllh.s
COMPILER_PATH=/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
LIBRARY_PATH=/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/i386/:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/i386/:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/i386/:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/:/usr/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-B'
'/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/' '-gdwarf-2' '-g1'
'-fwhole-program' '-O' '-m32' '-v' '-mtune=core2' '-dumpdir' './' '-dumpbase'
'pr41893-1.exe.ltrans0' '-fltrans' '-o' '/var/tmp//ccyf23lE.ltrans0.ltrans.o'
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-B'
'/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/' '-gdwarf-2' '-g1'
'-flto' '-fwhole-program' '-O' '-m32' '-v' '-o' 'pr41893-1.exe' '-mtune=core2'
 dsymutil pr41893-1.exe
warning: (i386) /var/tmp//ccyf23lE.ltrans0.ltrans.o unable to open object file
warning: no debug symbols in executable (-arch i386)

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-12-01 17:50:25 UTC ---
This failure appeared after r167289 but by r167301.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #2 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-12-01 18:05:00 UTC ---
Caused by...

Author: rguenth
Date: Tue Nov 30 10:00:51 2010
New Revision: 167292

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167292
Log:
2010-11-30  Richard Guenther  <rguenther@suse.de>

    PR lto/44986
    * gcc.c (main): Use the first input with a compiler as infile
    for link spec processing.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gcc.c

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2010.12.01 18:44:07
                 CC|rguenther at suse dot de    |rguenth at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-01 18:44:07 UTC ---
What's the difference of -v output caused by the patch?

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-12-01 20:30:57 UTC ---
Created attachment 22588
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22588
-v for gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 at r167291

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-12-01 20:31:45 UTC ---
Created attachment 22589
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22589
-v for gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 at r167292

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-12-01 20:32:53 UTC ---
Created attachment 22590
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22590
diff between -v for gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 at r167291 and
r167292

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #7 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-12-01 20:35:13 UTC ---
(In reply to comment #3)
> What's the difference of -v output caused by the patch?

The offending lines from the diff of -v output appears to be...


COMPILER_PATH=/Users/howarth/darwin_objdir/gcc/:/Users/howarth/darwin_objdir/gcc/

LIBRARY_PATH=/Users/howarth/darwin_objdir/gcc/i386/:/Users/howarth/darwin_objdir/gcc/i386/:/Users/howarth/darwin_objdir/gcc/:/Users/howarth/darwin_objdir/gcc/i386/:/Users/howarth/darwin_objdir/gcc/:/usr/lib/:/usr/lib/
-COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-B'
'/Users/howarth/darwin_objdir/gcc/' '-gdwarf-2' '-g1' '-fwhole-program' '-O'
'-m32' '-v' '-mtune=generic' '-dumpdir' './' '-dumpbase'
'pr41893-1.exe.ltrans0' '-fltrans' '-o'
'/var/folders/24/24glfkZF2RWeoU+87t2fYU+++TQ/-Tmp-//ccGj1vUo.ltrans0.ltrans.o'
+COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-B'
'/Users/howarth/darwin_objdir/gcc/' '-gdwarf-2' '-g1' '-fwhole-program' '-O'
'-m32' '-v' '-mtune=generic' '-dumpdir' './' '-dumpbase'
'pr41893-1.exe.ltrans0' '-fltrans' '-o'
'/var/folders/24/24glfkZF2RWeoU+87t2fYU+++TQ/-Tmp-//ccCBuImZ.ltrans0.ltrans.o'
+COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-B'
'/Users/howarth/darwin_objdir/gcc/' '-gdwarf-2' '-g1' '-flto' '-fwhole-program'
'-O' '-m32' '-v' '-o' 'pr41893-1.exe' '-mtune=generic'
+ dsymutil pr41893-1.exe
+warning: (i386)
/var/folders/24/24glfkZF2RWeoU+87t2fYU+++TQ/-Tmp-//ccCBuImZ.ltrans0.ltrans.o
unable to open object file
+warning: no debug symbols in executable (-arch i386)

where r167292 causes the compiler to burp out a second incorrect assignment for
COLLECT_GCC_OPTIONS after the first one.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-01 20:38:40 UTC ---
Can you also add -Wl,-debug and/or -debug (basically make sure collect2 and
lto-wrapper have verbosity on)?

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 20:46:11 UTC ---
my (quick) reading of this is that 
-- the bugfix made by 167292 has caused the source file to be recognized
-- causing dsymutil to fire up 
--  and revealing a pre-existing, probably unrelated problem.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-01 20:49:41 UTC ---
Works for me with -Wl,-debug (which doesn't delete intermediate files).

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #11 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-12-01 20:58:55 UTC ---
(In reply to comment #10)
> Works for me with -Wl,-debug (which doesn't delete intermediate files).

On x86_64-apple-darwin10 at r167292, adding -Wl,-debug inhibits the crash in
dsymutil.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 21:10:51 UTC ---
hm. 
on i686-darwin9 - adding -Wl,-debug simply suppresses the recognition of the
source file and dsymutil is not called (a manifestation of PR41751).

So there are two things; 

1. dsymutil is not being called correctly - depends on what's on the c/l 
(PR43751)
2. when it is called it looks like the object is being deleted too early.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 21:20:36 UTC ---
with -save-temps, dsymutil _is_ called and, indeed, the file complained about
is absent.
(I've a hunch that this could be related to the changes for simple-obj).

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-01 21:23:55 UTC ---
Also works with splitting the command into a -c and a link step.  Thus,

/Users/richard/obj/gcc/xgcc -B/Users/richard/obj/gcc/
/Users/richard/src/trunk/gcc/testsuite/gcc.dg/debug/pr41893-1.c  -gdwarf-2 -g1
-flto -fwhole-program -O 
/Users/richard/src/trunk/gcc/testsuite/gcc.dg/debug/pr41893-2.c  -lm   -c

/Users/richard/obj/gcc/xgcc -B/Users/richard/obj/gcc/ pr41893-1.o -gdwarf-2 -g1
-flto -fwhole-program -O pr41893-2.o  -lm   -o pr41893-1.exe
-flto-partition=none

does not fail.  -flto-partition=none makes it easier to debug, no make
is invocated (it's basically old LTO mode and not WHOPR).  darwin doesn't
seem to have an 'strace' command (bah).

lto-wrapper invokes xgcc:

/Users/richard/obj/gcc/lto-wrapper
/var/folders/2W/2WzmrwP7EFiRzkWthHumQ++++TM/-Tmp-//cc0Ff4e8.o
/var/folders/2W/2WzmrwP7EFiRzkWthHumQ++++TM/-Tmp-//ccWa94cZ.o

 /Users/richard/obj/gcc/xgcc -xlto -c -mmacosx-version-min=10.6.5 -B
/Users/richard/obj/gcc/ -gdwarf-2 -g1 -fwhole-program -O -flto-partition=none
-mtune=generic -dumpdir ./ -dumpbase pr41893-1.exe -o
/var/folders/2W/2WzmrwP7EFiRzkWthHumQ++++TM/-Tmp-//ccWI2XqX.lto.o
/var/folders/2W/2WzmrwP7EFiRzkWthHumQ++++TM/-Tmp-//cc0Ff4e8.o
/var/folders/2W/2WzmrwP7EFiRzkWthHumQ++++TM/-Tmp-//ccWa94cZ.o

/Users/richard/obj/gcc/collect-ld -dynamic -arch x86_64 -macosx_version_min
10.6.5 -weak_reference_mismatches non-weak -o pr41893-1.exe -lcrt1.10.5.o
-L/Users/richard/obj/gcc
/var/folders/2W/2WzmrwP7EFiRzkWthHumQ++++TM/-Tmp-//ccWI2XqX.lto.o -v
-lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem
@(#)PROGRAM:ld  PROJECT:ld64-97.14
Library search paths:
    /Users/richard/obj/gcc
    /usr/lib
    /usr/local/lib
Framework search paths:
    /Library/Frameworks/
    /System/Library/Frameworks/
warning: (x86_64)
/var/folders/2W/2WzmrwP7EFiRzkWthHumQ++++TM/-Tmp-//ccWI2XqX.lto.o unable to
open object file
warning: no debug symbols in executable (-arch x86_64)

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 21:34:19 UTC ---
splitting the command into compile and link steps will intentionally remove the
dsymutil step -  thus making the problem 'go away' ...

dsymutil should _only_ be called if there is a source file on the c/l 
(which would have its object deleted and thus be unavailable for debug).

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-01 21:51:18 UTC ---
On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> 
> --- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 21:34:19 UTC ---
> splitting the command into compile and link steps will intentionally remove the
> dsymutil step -  thus making the problem 'go away' ...
> 
> dsymutil should _only_ be called if there is a source file on the c/l 
> (which would have its object deleted and thus be unavailable for debug).

Huh, ok.  But the spec seems to call it unconditionally in the 
link-command-spec when -g is visible.  At least I can't see how
a "source file" is matched (and we now definitely do find object
files as source for the link step).

And the issue is probably that we match on the intermediate link
command but execute only after that is finished.

Well, that dsymutil hack looks like a hack.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 21:52:33 UTC ---
(In reply to comment #14)

> is invocated (it's basically old LTO mode and not WHOPR).  darwin doesn't
> seem to have an 'strace' command (bah).

dtruss/dtrace  might help.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 22:06:23 UTC ---
(In reply to comment #16)
> On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> > 
> > --- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 21:34:19 UTC ---
> > splitting the command into compile and link steps will intentionally remove the
> > dsymutil step -  thus making the problem 'go away' ...
> > 
> > dsymutil should _only_ be called if there is a source file on the c/l 
> > (which would have its object deleted and thus be unavailable for debug).
> 
> Huh, ok.  But the spec seems to call it unconditionally in the 
> link-command-spec when -g is visible.  At least I can't see how
> a "source file" is matched (and we now definitely do find object
> files as source for the link step).

it is matched (with the noted hacky & buggy behavior) by the list of suffixes.

> And the issue is probably that we match on the intermediate link
> command but execute only after that is finished.

OK

> Well, that dsymutil hack looks like a hack.

yeah - it's on my TODO (pr43751).
FWIW, some time ago, I did enquire about the difficulty of adding an
intentional additional post-link phase, with the feedback that it was prob. not
easy.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenther at suse dot de]

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

--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-02 08:52:14 UTC ---
On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> 
> --- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 22:06:23 UTC ---
> (In reply to comment #16)
> > On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote:
> > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> > > 
> > > --- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 21:34:19 UTC ---
> > > splitting the command into compile and link steps will intentionally remove the
> > > dsymutil step -  thus making the problem 'go away' ...
> > > 
> > > dsymutil should _only_ be called if there is a source file on the c/l 
> > > (which would have its object deleted and thus be unavailable for debug).
> > 
> > Huh, ok.  But the spec seems to call it unconditionally in the 
> > link-command-spec when -g is visible.  At least I can't see how
> > a "source file" is matched (and we now definitely do find object
> > files as source for the link step).
> 
> it is matched (with the noted hacky & buggy behavior) by the list of suffixes.
> 
> > And the issue is probably that we match on the intermediate link
> > command but execute only after that is finished.
> 
> OK
> 
> > Well, that dsymutil hack looks like a hack.
> 
> yeah - it's on my TODO (pr43751).
> FWIW, some time ago, I did enquire about the difficulty of adding an
> intentional additional post-link phase, with the feedback that it was prob. not
> easy.

I thought about adding it to the collect-ld script instead.

Why do we want it only if there is a .c source available?  That doesn't
make sense to me ... but i have no idea what dsymutil is supoosed to do,
so ...

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-02 09:09:49 UTC ---
(In reply to comment #19)
> On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote:

> > yeah - it's on my TODO (pr43751).
> > FWIW, some time ago, I did enquire about the difficulty of adding an
> > intentional additional post-link phase, with the feedback that it was prob. not
> > easy.
> 
> I thought about adding it to the collect-ld script instead.
> 
> Why do we want it only if there is a .c source available?  That doesn't
> make sense to me ... but i have no idea what dsymutil is supoosed to do,
> so ...

_any_ source, in fact -- hence PR43751 (because we don't even try to notice
Fortran at present).

----

OK. Without wishing to start any debate on whether the approach is "good" or
"bad".

The idea is that one saves time in the compile/debug loop by _not_ linking the
debug  - and leaving it in the object files.

This is fine until the c/l is of the form  " gcc some-source.ext    -o exe "
because then the object is temporary and deleted, thus not available for
debugging.

So, dsymtuil (which is a stand-alone debug-linker - used, in general, for the
packaging phase of a project) is invoked for such command lines.  It grabs the
debug from the files that will be deleted during the build.

this is quite helpful:
http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-02 09:50:48 UTC ---
On Thu, 2 Dec 2010, iains at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> 
> --- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-02 09:09:49 UTC ---
> (In reply to comment #19)
> > On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote:
> 
> > > yeah - it's on my TODO (pr43751).
> > > FWIW, some time ago, I did enquire about the difficulty of adding an
> > > intentional additional post-link phase, with the feedback that it was prob. not
> > > easy.
> > 
> > I thought about adding it to the collect-ld script instead.
> > 
> > Why do we want it only if there is a .c source available?  That doesn't
> > make sense to me ... but i have no idea what dsymutil is supoosed to do,
> > so ...
> 
> _any_ source, in fact -- hence PR43751 (because we don't even try to notice
> Fortran at present).
> 
> ----
> 
> OK. Without wishing to start any debate on whether the approach is "good" or
> "bad".
> 
> The idea is that one saves time in the compile/debug loop by _not_ linking the
> debug  - and leaving it in the object files.
> 
> This is fine until the c/l is of the form  " gcc some-source.ext    -o exe "
> because then the object is temporary and deleted, thus not available for
> debugging.
> 
> So, dsymtuil (which is a stand-alone debug-linker - used, in general, for the
> packaging phase of a project) is invoked for such command lines.  It grabs the
> debug from the files that will be deleted during the build.
> 
> this is quite helpful:
> http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme

Huh, but what do you do at make install time?  Copy the object files?
Extract the debug info and put it into the binary again?  Have a
special dsymutil make install hook?

Can we just disable this for the testsuite?

Richard.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #22 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-02 10:10:06 UTC ---
(In reply to comment #21)
> On Thu, 2 Dec 2010, iains at gcc dot gnu.org wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> > 
> > --- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-02 09:09:49 UTC ---
> > (In reply to comment #19)
> > > On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote:
> > 
> > > > yeah - it's on my TODO (pr43751).
> > > > FWIW, some time ago, I did enquire about the difficulty of adding an
> > > > intentional additional post-link phase, with the feedback that it was prob. not
> > > > easy.
> > > 
> > > I thought about adding it to the collect-ld script instead.
> > > 
> > > Why do we want it only if there is a .c source available?  That doesn't
> > > make sense to me ... but i have no idea what dsymutil is supoosed to do,
> > > so ...
> > 
> > _any_ source, in fact -- hence PR43751 (because we don't even try to notice
> > Fortran at present).
> > 
> > ----
> > 
> > OK. Without wishing to start any debate on whether the approach is "good" or
> > "bad".
> > 
> > The idea is that one saves time in the compile/debug loop by _not_ linking the
> > debug  - and leaving it in the object files.
> > 
> > This is fine until the c/l is of the form  " gcc some-source.ext    -o exe "
> > because then the object is temporary and deleted, thus not available for
> > debugging.
> > 
> > So, dsymtuil (which is a stand-alone debug-linker - used, in general, for the
> > packaging phase of a project) is invoked for such command lines.  It grabs the
> > debug from the files that will be deleted during the build.
> > 
> > this is quite helpful:
> > http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme
> 
> Huh, but what do you do at make install time?  Copy the object files?
> Extract the debug info and put it into the binary again?  Have a
> special dsymutil make install hook?

At install-time dsymutil is run and the relevant xxx.dSYM is installed along
with the objects, where required.

AFAICS, this is already handled within auto* & gcc (the gcc libraries appear to
build dSYMs).

> Can we just disable this for the testsuite?

well, one possibility to resolve this, is to disable the 'automatic' running of
dsymutil - add a '-syms' flag, and require that the user adds that flag along
with the debug ones.   In which case, it would be automatically absent from the
test-suite.   It's a bit of a cop-out and I don't know if it would be
acceptable to Darwin maintainers .. but it's a thought.

The problem showing in this PR would still arise for a user invoking such a
flag along with flto -- so we need to fix it at some stage (but I wouldn't say
it was in any way critical).

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-02 10:14:22 UTC ---
(In reply to comment #22)

> At install-time dsymutil is run and the relevant xxx.dSYM is installed along
> with the objects, where required.

s/objects/exes/

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mrs at gcc dot gnu.org]

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

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org

--- Comment #24 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2010-12-03 00:26:37 UTC ---
The lto people need to engineer a design in which the debug information is left
around in .o files, and those files are read at the very last step in a link,
to collect the debug information from them and persist that information into
the filesystem.  They are removing .o files before the end of the final link. 
To the extent those files have debug information in them, this can't work.

I could not find the last invocation of gcc that fails.  If someone could point
that out, I might be able to suggest a work around that just disappears debug
information until such time as the first bug is fixed.  Essentially, you can
remove -g* from that line and disappear the collection of the debug
information.  Another solution would be to not have any .c, .cc, .C, .cpp, .cp,
.c++, .cxx, .CPP, .m, .mm, .f, or .s files on that line.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenther at suse dot de]

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

--- Comment #25 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-03 10:47:49 UTC ---
On Fri, 3 Dec 2010, mrs at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> 
> mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |mrs at gcc dot gnu.org
> 
> --- Comment #24 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2010-12-03 00:26:37 UTC ---
> The lto people need to engineer a design in which the debug information is left
> around in .o files, and those files are read at the very last step in a link,
> to collect the debug information from them and persist that information into
> the filesystem.  They are removing .o files before the end of the final link. 
> To the extent those files have debug information in them, this can't work.
> 
> I could not find the last invocation of gcc that fails.  If someone could point
> that out, I might be able to suggest a work around that just disappears debug
> information until such time as the first bug is fixed.  Essentially, you can
> remove -g* from that line and disappear the collection of the debug
> information.  Another solution would be to not have any .c, .cc, .C, .cpp, .cp,
> .c++, .cxx, .CPP, .m, .mm, .f, or .s files on that line.

I didn't manage to prove the following theory but it's the only that
makes sense.

What I think happens is the following:

User says

 gcc -o t t.c -flto

We now do the usual compile

 ./cc1 -c -o /tmp/xyz.o t.c -flto

and now execute the link-spec which matches the symtool thing
(but on the wrong object file!).  So, we now link.  Which will do

 collect2 ...

which executes lto-wrapper which executes

 gcc -c -x lto -o /tmp/abc.o /tmp/xyz.o -flto

and then collect2 continues and links

 collect2-ld ... -o t /tmp/abc.o

only _now_ dsymutil is invoked (from the first link-spec!) and
on /tmp/xyz.o, which isn't the correct object file either.
But somehow that intermediate file has disappeared at this point
(I have yet to see who is responsible for cleaning up that one
and when it does so).

Thus, the setup is broken anyhow, even if we manage to retain
the object file for long enough.

The darwin people have to design a more robust way to run
dsymutil.

Richard.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenther at suse dot de]

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

--- Comment #26 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-03 10:51:06 UTC ---
On Fri, 3 Dec 2010, rguenther at suse dot de wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> 
> --- Comment #25 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-03 10:47:49 UTC ---
> On Fri, 3 Dec 2010, mrs at gcc dot gnu.org wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> > 
> > mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:
> > 
> >            What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >                  CC|                            |mrs at gcc dot gnu.org
> > 
> > --- Comment #24 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2010-12-03 00:26:37 UTC ---
> > The lto people need to engineer a design in which the debug information is left
> > around in .o files, and those files are read at the very last step in a link,
> > to collect the debug information from them and persist that information into
> > the filesystem.  They are removing .o files before the end of the final link. 
> > To the extent those files have debug information in them, this can't work.
> > 
> > I could not find the last invocation of gcc that fails.  If someone could point
> > that out, I might be able to suggest a work around that just disappears debug
> > information until such time as the first bug is fixed.  Essentially, you can
> > remove -g* from that line and disappear the collection of the debug
> > information.  Another solution would be to not have any .c, .cc, .C, .cpp, .cp,
> > .c++, .cxx, .CPP, .m, .mm, .f, or .s files on that line.
> 
> I didn't manage to prove the following theory but it's the only that
> makes sense.
> 
> What I think happens is the following:
> 
> User says
> 
>  gcc -o t t.c -flto
> 
> We now do the usual compile
> 
>  ./cc1 -c -o /tmp/xyz.o t.c -flto
> 
> and now execute the link-spec which matches the symtool thing
> (but on the wrong object file!).  So, we now link.  Which will do
> 
>  collect2 ...
> 
> which executes lto-wrapper which executes
> 
>  gcc -c -x lto -o /tmp/abc.o /tmp/xyz.o -flto
> 
> and then collect2 continues and links
> 
>  collect2-ld ... -o t /tmp/abc.o
> 
> only _now_ dsymutil is invoked (from the first link-spec!) and
> on /tmp/xyz.o, which isn't the correct object file either.
> But somehow that intermediate file has disappeared at this point
> (I have yet to see who is responsible for cleaning up that one
> and when it does so).
> 
> Thus, the setup is broken anyhow, even if we manage to retain
> the object file for long enough.
> 
> The darwin people have to design a more robust way to run
> dsymutil.

Btw, I would have tried to dig deeper but darwin lacks basic tools
such as strace which I am familiar with, so I was lost (fortunately
for you I now do have access to a darwin x86 machine).

So if you can hint me at what's the equivalent of
  strace -f -e unlink,execve -o log ./xgcc ...
on darwin that would help.

Richard.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #27 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-03 11:29:59 UTC ---
(In reply to comment #26)
> On Fri, 3 Dec 2010, rguenther at suse dot de wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> > 
> > --- Comment #25 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-03 10:47:49 UTC ---
> > On Fri, 3 Dec 2010, mrs at gcc dot gnu.org wrote:
> > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> > > 
> > > mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:
> > > 
> > >            What    |Removed                     |Added
> > > ----------------------------------------------------------------------------
> > >                  CC|                            |mrs at gcc dot gnu.org
> > > 
> > > --- Comment #24 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2010-12-03 00:26:37 UTC ---
> > > The lto people need to engineer a design in which the debug information is left
> > > around in .o files, and those files are read at the very last step in a link,
> > > to collect the debug information from them and persist that information into
> > > the filesystem.  They are removing .o files before the end of the final link. 
> > > To the extent those files have debug information in them, this can't work.
> > > 
> > > I could not find the last invocation of gcc that fails.  If someone could point
> > > that out, I might be able to suggest a work around that just disappears debug
> > > information until such time as the first bug is fixed.  Essentially, you can
> > > remove -g* from that line and disappear the collection of the debug
> > > information.  Another solution would be to not have any .c, .cc, .C, .cpp, .cp,
> > > .c++, .cxx, .CPP, .m, .mm, .f, or .s files on that line.

r167292 has fixed the problem with the suffix recognition.
(I suspect that the bug you fixed predates the inclusion of the spec, thus the
spec has never worked 100% on trunk)

> > I didn't manage to prove the following theory but it's the only that
> > makes sense.
> > 
> > What I think happens is the following:
> > 
> > User says
> > 
> >  gcc -o t t.c -flto
> > 
> > We now do the usual compile
> > 
> >  ./cc1 -c -o /tmp/xyz.o t.c -flto
> > 
> > and now execute the link-spec which matches the symtool thing
> > (but on the wrong object file!).  So, we now link.  Which will do
> > 
> >  collect2 ...
> > 
> > which executes lto-wrapper which executes
> > 
> >  gcc -c -x lto -o /tmp/abc.o /tmp/xyz.o -flto
> > 
> > and then collect2 continues and links
> > 
> >  collect2-ld ... -o t /tmp/abc.o
> > 
> > only _now_ dsymutil is invoked (from the first link-spec!) and
> > on /tmp/xyz.o, which isn't the correct object file either.
> > But somehow that intermediate file has disappeared at this point
> > (I have yet to see who is responsible for cleaning up that one
> > and when it does so).

my understanding is that dsymutil only takes the linked executable as its
command line argument - and looks up the objects from the tables therein.

The debug is then extracted from those objects, linked and placed into the
.dSYM and then the objects are unlinked.

Therefore, somehow I assume that the linked exec is referring to an object
which has gone away.
(if it's actually the wrong object,  then that's a potentially more serious
issue).

> > Thus, the setup is broken anyhow, even if we manage to retain
> > the object file for long enough.
> > 
> > The darwin people have to design a more robust way to run
> > dsymutil.

AFAIK dsymutil requires only (a) the linked exec. and (b) that the objects used
to link it are still available.  
It's not obvious to me how we (within the FSF community) can simplify that or
make it more robust.

> Btw, I would have tried to dig deeper but darwin lacks basic tools
> such as strace which I am familiar with, so I was lost (fortunately
> for you I now do have access to a darwin x86 machine).
> 
> So if you can hint me at what's the equivalent of
>   strace -f -e unlink,execve -o log ./xgcc ...
> on darwin that would help.

sudo dtruss -f  -t syscall ./xgcc...  > log

might be helpful, cheers,  Iain

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #28 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-03 12:10:42 UTC ---
another thing that might help is to hack gcc/spec to put "dsymutil --symtab"
that causes dsymutil to dump what it found in the exec and exit without doing
the debug-link.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mikestump at comcast dot net]

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

--- Comment #29 from Mike Stump <mikestump at comcast dot net> 2010-12-03 23:13:02 UTC ---
> The darwin people have to design a more robust way to run dsymutil.


Ok.  How's this, you must run LINK_COMMAND_SPEC to link.  When you run it, any
temporary real .o files created by the compilation process cannot be removed
until after it finishes running, including any sub-invocations of the compiler
that contribute content.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenther at suse dot de]

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

--- Comment #30 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-03 23:20:54 UTC ---
On Fri, 3 Dec 2010, mikestump at comcast dot net wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> 
> --- Comment #29 from Mike Stump <mikestump at comcast dot net> 2010-12-03 23:13:02 UTC ---
> > The darwin people have to design a more robust way to run dsymutil.
> 
> 
> Ok.  How's this, you must run LINK_COMMAND_SPEC to link.  When you run it, any
> temporary real .o files created by the compilation process cannot be removed
> until after it finishes running, including any sub-invocations of the compiler
> that contribute content.

yes, I would have expected that this happens already.  Now, I (or
somebody else) needs to take the time and investigate why this
doesn't happen.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mikestump at comcast dot net]

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

--- Comment #31 from Mike Stump <mikestump at comcast dot net> 2010-12-04 00:18:07 UTC ---
On Dec 3, 2010, at 3:20 PM, rguenther at suse dot de wrote:
> yes, I would have expected that this happens already.  Now, I (or
> somebody else) needs to take the time and investigate why this
> doesn't happen.

Ah, I can explain it, collect2 does `stuff', and what it does is to remove the
lto temporary files, early.  The below are the files that are too early, and
will `fix' the issue.

Index: collect2.c
===================================================================
--- collect2.c    (revision 167409)
+++ collect2.c    (working copy)
@@ -1056,7 +1056,9 @@
       fork_execute ("ld", out_lto_ld_argv);
       free (lto_ld_argv);

+#if 0
       maybe_unlink_list (lto_o_files);
+#endif
     }
   else if (force)
     {

If collect2 was folded into gcc.c and all the lto stuff was flat, inside gcc.c
and then we let record_temp_file register _all_ the temporary files, and the
let gcc.c delete the temporary files at the end, all work work just fine.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #32 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-12-04 02:10:50 UTC ---
While the hack in Comment 31 produces the missing .dSYM output for -g -flto, it
also leave behind the temporary *.ltrans0.ltrans.o files in /var/tmp at the
end. A simple compile shows...


[frodo:~] howarth% ./dist/bin/gcc -flto -g -v himenoBMTxpa.c
Using built-in specs.
COLLECT_GCC=./dist/bin/gcc
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20101203 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/cc1 -quiet -v
-D__DYNAMIC__ himenoBMTxpa.c -fPIC -feliminate-unused-debug-symbols -quiet
-dumpbase himenoBMTxpa.c -mmacosx-version-min=10.6.5 -mtune=core2 -auxbase
himenoBMTxpa -g -version -flto -o /var/tmp//ccAAPCUI.s
GNU C (GCC) version 4.6.0 20101203 (experimental) (x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../../x86_64-apple-darwin10.5.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/include
 /Users/howarth/dist/include
 /Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C (GCC) version 4.6.0 20101203 (experimental) (x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 27436f303ba35e8877de0a62c5c2d06f
himenoBMTxpa.c: In function 'main':
himenoBMTxpa.c:79:5: warning: incompatible implicit declaration of built-in
function 'strcpy' [enabled by default]
himenoBMTxpa.c: In function 'set_param':
himenoBMTxpa.c:226:5: warning: incompatible implicit declaration of built-in
function 'exit' [enabled by default]
himenoBMTxpa.c: In function 'newMat':
himenoBMTxpa.c:239:5: warning: incompatible implicit declaration of built-in
function 'malloc' [enabled by default]
himenoBMTxpa.c: In function 'clearMat':
himenoBMTxpa.c:248:5: warning: incompatible implicit declaration of built-in
function 'free' [enabled by default]
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o /var/tmp//cci8rGh2.o
/var/tmp//ccAAPCUI.s
COMPILER_PATH=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/
LIBRARY_PATH=/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/collect2 -flto
-dynamic -arch x86_64 -macosx_version_min 10.6.5 -weak_reference_mismatches
non-weak -o a.out -lcrt1.10.5.o
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../..
/var/tmp//cci8rGh2.o -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem
 ./dist/bin/gcc @/var/tmp//cctadu4J.args
Using built-in specs.
COLLECT_GCC=./dist/bin/gcc
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20101203 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans-output-list=/var/tmp//ccIno63U.ltrans.out' '-fwpa'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto1 -fPIC
-feliminate-unused-debug-symbols -quiet -dumpbase cci8rGh2.o
-mmacosx-version-min=10.6.5 -mtune=core2 -auxbase cci8rGh2 -g -version
-fltrans-output-list=/var/tmp//ccIno63U.ltrans.out -fwpa @/var/tmp//cc1Qg4SB
GNU GIMPLE (GCC) version 4.6.0 20101203 (experimental)
(x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.6.0 20101203 (experimental)
(x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COMPILER_PATH=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/
LIBRARY_PATH=/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans-output-list=/var/tmp//ccIno63U.ltrans.out' '-fwpa'
 ./dist/bin/gcc @/var/tmp//ccgwI0EO.args
Using built-in specs.
COLLECT_GCC=./dist/bin/gcc
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20101203 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans' '-o' '/var/tmp//ccIno63U.ltrans0.ltrans.o'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto1 -fPIC
-feliminate-unused-debug-symbols -quiet -dumpbase ccIno63U.ltrans0.o
-mmacosx-version-min=10.6.5 -mtune=core2 -auxbase-strip
/var/tmp//ccIno63U.ltrans0.ltrans.o -g -version -fltrans @/var/tmp//ccyT9Yzo -o
/var/tmp//ccOcfTrn.s
GNU GIMPLE (GCC) version 4.6.0 20101203 (experimental)
(x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.6.0 20101203 (experimental)
(x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans' '-o' '/var/tmp//ccIno63U.ltrans0.ltrans.o'
 as -arch x86_64 -force_cpusubtype_ALL -o /var/tmp//ccIno63U.ltrans0.ltrans.o
/var/tmp//ccOcfTrn.s
COMPILER_PATH=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/
LIBRARY_PATH=/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans' '-o' '/var/tmp//ccIno63U.ltrans0.ltrans.o'
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 dsymutil a.out
[frodo:~] howarth% 
[frodo:~] howarth% ./dist/bin/gcc -flto -g -v himenoBMTxpa.c
Using built-in specs.
COLLECT_GCC=./dist/bin/gcc
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20101203 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/cc1 -quiet -v
-D__DYNAMIC__ himenoBMTxpa.c -fPIC -feliminate-unused-debug-symbols -quiet
-dumpbase himenoBMTxpa.c -mmacosx-version-min=10.6.5 -mtune=core2 -auxbase
himenoBMTxpa -g -version -flto -o /var/tmp//ccHiF8rF.s
GNU C (GCC) version 4.6.0 20101203 (experimental) (x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../../x86_64-apple-darwin10.5.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/include
 /Users/howarth/dist/include
 /Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C (GCC) version 4.6.0 20101203 (experimental) (x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 27436f303ba35e8877de0a62c5c2d06f
himenoBMTxpa.c: In function 'main':
himenoBMTxpa.c:79:5: warning: incompatible implicit declaration of built-in
function 'strcpy' [enabled by default]
himenoBMTxpa.c: In function 'set_param':
himenoBMTxpa.c:226:5: warning: incompatible implicit declaration of built-in
function 'exit' [enabled by default]
himenoBMTxpa.c: In function 'newMat':
himenoBMTxpa.c:239:5: warning: incompatible implicit declaration of built-in
function 'malloc' [enabled by default]
himenoBMTxpa.c: In function 'clearMat':
himenoBMTxpa.c:248:5: warning: incompatible implicit declaration of built-in
function 'free' [enabled by default]
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o /var/tmp//ccSn8GAt.o
/var/tmp//ccHiF8rF.s
COMPILER_PATH=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/
LIBRARY_PATH=/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/collect2 -flto
-dynamic -arch x86_64 -macosx_version_min 10.6.5 -weak_reference_mismatches
non-weak -o a.out -lcrt1.10.5.o
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../..
/var/tmp//ccSn8GAt.o -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem
 ./dist/bin/gcc @/var/tmp//ccpfJ4GS.args
Using built-in specs.
COLLECT_GCC=./dist/bin/gcc
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20101203 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans-output-list=/var/tmp//ccKpeG3H.ltrans.out' '-fwpa'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto1 -fPIC
-feliminate-unused-debug-symbols -quiet -dumpbase ccSn8GAt.o
-mmacosx-version-min=10.6.5 -mtune=core2 -auxbase ccSn8GAt -g -version
-fltrans-output-list=/var/tmp//ccKpeG3H.ltrans.out -fwpa @/var/tmp//ccHXxoZR
GNU GIMPLE (GCC) version 4.6.0 20101203 (experimental)
(x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.6.0 20101203 (experimental)
(x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COMPILER_PATH=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/
LIBRARY_PATH=/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans-output-list=/var/tmp//ccKpeG3H.ltrans.out' '-fwpa'
 ./dist/bin/gcc @/var/tmp//ccL9KPbz.args
Using built-in specs.
COLLECT_GCC=./dist/bin/gcc
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20101203 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans' '-o' '/var/tmp//ccKpeG3H.ltrans0.ltrans.o'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto1 -fPIC
-feliminate-unused-debug-symbols -quiet -dumpbase ccKpeG3H.ltrans0.o
-mmacosx-version-min=10.6.5 -mtune=core2 -auxbase-strip
/var/tmp//ccKpeG3H.ltrans0.ltrans.o -g -version -fltrans @/var/tmp//ccX6FGrc -o
/var/tmp//ccnCT2j2.s
GNU GIMPLE (GCC) version 4.6.0 20101203 (experimental)
(x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.6.0 20101203 (experimental)
(x86_64-apple-darwin10.5.0)
    compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans' '-o' '/var/tmp//ccKpeG3H.ltrans0.ltrans.o'
 as -arch x86_64 -force_cpusubtype_ALL -o /var/tmp//ccKpeG3H.ltrans0.ltrans.o
/var/tmp//ccnCT2j2.s
COMPILER_PATH=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/
LIBRARY_PATH=/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans' '-o' '/var/tmp//ccKpeG3H.ltrans0.ltrans.o'
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 dsymutil a.out

Why can't lto1 call maybe_unlink_list (lto_o_files) instead?

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #33 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-12-04 03:18:41 UTC ---
Using the patch...

Index: gcc/collect2.c
===================================================================
--- gcc/collect2.c    (revision 167430)
+++ gcc/collect2.c    (working copy)
@@ -1055,8 +1055,10 @@
          optimized by the LTO with the temporary file generated by the LTO. 
*/
       fork_execute ("ld", out_lto_ld_argv);
       free (lto_ld_argv);
-
+#if 0
       maybe_unlink_list (lto_o_files);
+#endif
+      printf("would have executed maybe_unlink_list\n");
     }
   else if (force)
     {

...the previous test compilation of "gcc -flto -g -v himenoBMTxpa.c", changes
to...

COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans' '-o' '/var/tmp//cc52uGqn.ltrans0.ltrans.o'
would have executed maybe_unlink_list
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 dsymutil a.out

and is the only instance of that call.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenther at suse dot de]

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

--- Comment #34 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-04 10:27:58 UTC ---
On Sat, 4 Dec 2010, mikestump at comcast dot net wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> 
> --- Comment #31 from Mike Stump <mikestump at comcast dot net> 2010-12-04 00:18:07 UTC ---
> On Dec 3, 2010, at 3:20 PM, rguenther at suse dot de wrote:
> > yes, I would have expected that this happens already.  Now, I (or
> > somebody else) needs to take the time and investigate why this
> > doesn't happen.
> 
> Ah, I can explain it, collect2 does `stuff', and what it does is to remove the
> lto temporary files, early.  The below are the files that are too early, and
> will `fix' the issue.
> 
> Index: collect2.c
> ===================================================================
> --- collect2.c    (revision 167409)
> +++ collect2.c    (working copy)
> @@ -1056,7 +1056,9 @@
>        fork_execute ("ld", out_lto_ld_argv);
>        free (lto_ld_argv);
> 
> +#if 0
>        maybe_unlink_list (lto_o_files);
> +#endif
>      }
>    else if (force)
>      {
> 
> If collect2 was folded into gcc.c and all the lto stuff was flat, inside gcc.c
> and then we let record_temp_file register _all_ the temporary files, and the
> let gcc.c delete the temporary files at the end, all work work just fine.

Well - yes.  There is the complication called linker-plugin (which
is also removing the files).  You can't fold the linker plugin
(thus, the linker) into the gcc driver.

I thought a long time on what a solution to the problem could be and
only see the following:

 - The GCC driver is the place where we can detect if we need to
   execute dsymutil because we'll only have temporary object files.
   The GCC driver needs to arrange for a new -dsym option being
   passed to the linker (which might be collect2 for example)

 - The _linker_ (or collect2 for example) is responsible for
   invoking dsymutil if there is a -dsym option on the command-line.
   Only at link time we are sure all object files are still around.

If darwin only ever uses collect2 (and not the linker-plugin) then
this would be a easy and localized change.  It would of course also
offer the user to specify that he wants dsymutil to run.

Richard.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mikestump at comcast dot net]

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

--- Comment #35 from Mike Stump <mikestump at comcast dot net> 2010-12-05 21:13:30 UTC ---
Surely this design isn't complete as it doesn't cover the changes or the
requirements for lto.  Without those, I can't review the design to see if it is
sufficient to actually fix the problem at hand.  The problem is there are
temporary files removed by subpasses during the subpass.  The above doesn't
lengthen the lifetime of those temporary files, so can't fix the problem.

Compare and contrast another potential design:

Add an environment variable that identifies a file in which additions can be
made of temporary object files to remove once the link is done.  If any subpart
of the compilation process wants to create to create intermediate .o files,
they can instead write into that named file, the names of the temporary files
to delete, then the top level driver (one with no environment variable set, can
delete them, at the very end.  This even works for linker plugin files and
cover just about every type of tech or architecture for the compilation process
save distribution, caching and compilation server.  I'd propose we handle those
later, as necessary.

The advantages of this over the last one is, it is complete, it would always
work, regardless of nesting complexities, doesn't require any changes to `ld',
and works, even when collect2 isn't used.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenth at gcc dot gnu.org]

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

--- Comment #36 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-05 21:57:06 UTC ---
(In reply to comment #35)
> Surely this design isn't complete as it doesn't cover the changes or the
> requirements for lto.  Without those, I can't review the design to see if it is
> sufficient to actually fix the problem at hand.  The problem is there are
> temporary files removed by subpasses during the subpass.  The above doesn't
> lengthen the lifetime of those temporary files, so can't fix the problem.

Sure it fixes the problem.  dsymutil has to be called from the linker
at which point in time the temporary files are obviously still available
(as compared to the time when the parent driver process invokes it)

> Compare and contrast another potential design:
> 
> Add an environment variable that identifies a file in which additions can be
> made of temporary object files to remove once the link is done.

You probably need a temporary file to store the temporary files due
to limits of environ variable content length.  That file can be similar
to -fresolution handling, which is a temporary file managed by the
driver.

>  If any subpart
> of the compilation process wants to create to create intermediate .o files,
> they can instead write into that named file, the names of the temporary files
> to delete, then the top level driver (one with no environment variable set, can
> delete them, at the very end.  This even works for linker plugin files and
> cover just about every type of tech or architecture for the compilation process
> save distribution, caching and compilation server.  I'd propose we handle those
> later, as necessary.

Sure, that also works.  But it doesn't work for example for makefile
managed temporaries, like

%.o: %.c
   gcc -c $< -o $@

foo: a.o b.o
   gcc -o t $<

dsymutil is not called.   And at install time the temporary objects are gone.
So you need a way to handle the above anyway, and I don't see how the above
is really different from the current problem.  If you'd have dsymutil
invoked from the linker then the problem would not exist.

> The advantages of this over the last one is, it is complete, it would always
> work, regardless of nesting complexities, doesn't require any changes to `ld',
> and works, even when collect2 isn't used.

Well.

Whoever will implement something will probably decide on what he'll implement
(which means, it'll not be me).  If you want to go with managing everything
from the parent driver process I suggest to use sth similar to -fresolution
and not an environment variable.

A linker option to invoke dsymutil sounds useful for me anyway (for the
above problems with makefiles), so fixing the LTO problem with that
sounds then easy.

Managing all temporary files from the outermost driver process will at
least cause the worst case diskspace usage and doesn't allow any
optimization there.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mrs at gcc dot gnu.org]

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

--- Comment #37 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2010-12-07 00:25:45 UTC ---
Created attachment 22664
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22664
-dsym linker patch

Ok, I decided to implement it and try it out, since you had a plan...  It
appears to work well enough.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mrs at gcc dot gnu.org]

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

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #38 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2010-12-07 00:34:11 UTC ---
Still need to test the patch out.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenth at gcc dot gnu.org]

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

--- Comment #39 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-07 09:46:51 UTC ---
The patch looks reasonable to me.  -dsym and -idsym need addition to common.opt
as driver option I think and eventually need documentation if they are supposed
to be used by the user as well.

Thanks,
Richard.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[joseph at codesourcery dot com]

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

--- Comment #40 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-12-07 13:20:55 UTC ---
On Tue, 7 Dec 2010, rguenth at gcc dot gnu.org wrote:

> The patch looks reasonable to me.  -dsym and -idsym need addition to 
> common.opt as driver option I think and eventually need documentation if 
> they are supposed to be used by the user as well.

As I read this patch they are collect2 options, not driver options, and 
can't be passed directly to the driver.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mrs at gcc dot gnu.org]

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

--- Comment #41 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2010-12-07 16:34:34 UTC ---
Yeah, I was thinking of letting them bake just a little bit.  -dsym would be
the only driver option, if we make it one.  Testing of the C languages and
fortran seems to have gone well on x86_64-darwin10.  java/ada/go weren't
tested, though, don't expect any issues with them.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mikestump at comcast dot net]

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

--- Comment #42 from Mike Stump <mikestump at comcast dot net> 2010-12-07 16:42:04 UTC ---
Oh, one can use -Wl,-dsym in the time being with this patch.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mrs at gcc dot gnu.org]

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

--- Comment #43 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2010-12-08 20:11:13 UTC ---
Author: mrs
Date: Wed Dec  8 20:11:05 2010
New Revision: 167603

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167603
Log:
    PR debug/46749
    * config/darwin.h (COLLECT_RUN_DSYMUTIL): Add.
    (DSYMUTIL_SPEC): Use `linker' flags instead to handle lto
    better.
    * config/darwin9.h (COLLECT_RUN_DSYMUTIL): Add.
    (DSYMUTIL_SPEC): Use `linker' flags instead to handle lto
    better.
    * collect2.c (post_ld_pass): Add.
    (process_args): Add.
    (maybe_run_lto_and_relink): Call post_ld_pass after ld.
    (main): Likewise.  Call process_args.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/collect2.c
    trunk/gcc/config/darwin.h
    trunk/gcc/config/darwin9.h

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mrs at gcc dot gnu.org]

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

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #44 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2010-12-08 23:12:31 UTC ---
Should be fixed now.  I noticed major problems with debug information with LTO,
such as 46796.