[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
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=gccview=revrev=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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 m...@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.
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
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
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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 m...@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
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
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
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
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 m...@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
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 m...@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
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 m...@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
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
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
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
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
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
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
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
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
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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 m...@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
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
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=gccview=revrev=167292 Log: 2010-11-30 Richard Guenther rguent...@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
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
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
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
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
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
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
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
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
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
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
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
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/2WzmrwP7EFiRzkWthHumQTM/-Tmp-//cc0Ff4e8.o /var/folders/2W/2WzmrwP7EFiRzkWthHumQTM/-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/2WzmrwP7EFiRzkWthHumQTM/-Tmp-//ccWI2XqX.lto.o /var/folders/2W/2WzmrwP7EFiRzkWthHumQTM/-Tmp-//cc0Ff4e8.o /var/folders/2W/2WzmrwP7EFiRzkWthHumQTM/-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/2WzmrwP7EFiRzkWthHumQTM/-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/2WzmrwP7EFiRzkWthHumQTM/-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
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
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
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
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.
