This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch Darwin] proposal for a 4.6 work-around to dsymutil calling issues.
On Dec 2, 2010, at 1:12 PM, IainS wrote:
> On 2 Dec 2010, at 19:59, Mike Stump wrote:
>
>> On Dec 2, 2010, at 3:45 AM, IainS wrote:
>>> PR43751 and PR46749 show that we have a problem with the existing way in which dsymutil is called by trying to recognize that the c/l contains a source file.
>>
>> So, you propose to just remove the feature and break one of the fundamental usage models of compilation on unix environments, because....
>
> ... I proposed to provide an alternative .. but .. I will finish the sentence anyway ;-) .....
> ... it doesn't work reliably or consistently (with the current compiler)
I disagree. I think the proper direction would be to fix the bugs, so that it works 100% instead of 90%.
> gcc test.c -o hc -g3 ==> produces a dSYM
> gcc test.c -o hc -g3 -lmylib ==> does not.
>
> (I don't think that is obvious)
$ ls -lt DEL.dSYM
ls: DEL.dSYM: No such file or directory
$ ./xgcc -B./ t.c -o DEL -g3 -L. -lmylib
$ ls -lt DEL.dSYM
total 0
drwxr-xr-x 4 mrs mrs 136 Dec 2 13:26 Contents
? Now, I don't doubt there are bugs, but at least for me the above doesn't seem to be one of them.
> - I suspect that we have no (more) problems adding (e.g.) Fortran than the ones we already know about with dsymutil and current c/debug.
If you run the fortran test suite with the %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm|.s: condition removed from darwin9.h, are there no regressions? Does debugging appear to then work in fortran? If so, let's add the fortran suffixes to the list. We know it is necessary, though, maybe not sufficient.
I just tried it in my tree, it did exactly what I expected. It ran dsymutil, then it unlinked the .o files. I've added a comment in the PR for you to add a testcase, as trivially, I don't yet have it. Maybe this issue if just lto related? I'm in a non-lto tree, currently.
> - you know from previous attempts that enabling dsymutil for the Fortran suite will result in a whole load of spurious fallout (hence the hack wrapper from x months back). However, the errors appear to be just that - spurious - and the dSYM seems reasonably OK.
>
> - for Java I've only succeeded in debugging with "-save-temps" ... the dSYM seg-faults the installed gdb on Darwin9 & 10.
Well, lots of possibilities exist:
Then either, we should recommend FSF gdb (if it work) for java, and/or bug report it to Apple, or try llvm's debugger on the grounds that Apple is unlikely to continue forward with gdb and/or use stabs with java... Lots of possibilities.
> well, my view is that it's already at least partially broken, and/or inconsistent for the current suite of gcc languages.
Yes, that may well be the case, but to break it further doesn't help the people that use it reliably today.
> If we {cannot,do not have time to} fix this within 4.6 ...
> ... I would suggest that a documented, working, facility where the user puts "-dsym" on the c/l to get a dSYM is better than something which works part-time (and not at all for Fortran) --- after all, the user has to put -g* to get debug output anyway -- it's not like we're asking for something radically different.
I don't favor adding flags and documentation for hack arounds. I'd rather just fix the real problem. I have yet to have someone even say what the real problem is. I suspect lto is just a little bit wrong.