- removed comment
Enable symbols for backtraces
The attached patch adds the option -rdynamic to CFLAGS and CXXFLAGS for all optionlists using the Intel or GCC compilers. This makes backtraces from Carpet (new in ET_2011_10) contain meaningful symbols rather than gibberish or nothing. This has been present in datura and damiana for a long time and works well.
From man gcc:
-rdynamic
Pass the flag -export-dynamic to the ELF linker, on targets that
support it. This instructs the linker to add all symbols, not only
used ones, to the dynamic symbol table. This option is needed for
some uses of “dlopen” or to allow obtaining backtraces from within a
program.
Given the usefulness of good backtraces and the nature of this option, I think it might be feasible and useful to get this in before the release, assuming that there will be another round of tests.
I have only enabled this for GCC and Intel because I haven’t tested it with other compilers, nor with Fortran. I clearly haven't tested this on all the machines it applies to.
Keyword:
Comments (10)
-
-
reporter - removed comment
I agree that we should be careful, and in my judgement the effect of adding some additional debugging symbols should be minor, in comparison to other changes that you can imagine. Of course we cannot ever be sure, but I weighed this up against the benefit of having useful backtraces for the duration of the release, and decided it was a risk worth taking, given that we usually run all the test cases on all machines once with the final frozen version. However, I leave the decision to you.
The option -rdynamic is a compiler option - see the manual entry above. I'm not sure why we don't use the -export-dynamic flag directly with the linker. I discovered rdynamic using google over a year ago and used it, and it worked, both on gcc and intel. The "on architectures that support it" might indicate that -export-dynamic would give an error on some architectures, so maybe we are using some logic in rdynamic.
-
- removed comment
My priority at the moment is to ensure that we can smoothly guide the release out of the door. It is too late for new features. Who knows what can go wrong -- syntax errors in option lists, linkers running out of memory because they have to handle many more symbols, errors because of duplicate symbols that are only detected with this option, etc.
The decision is up to Frank, because he is the release manager.
-
reporter - changed milestone to ET_2012_05
- removed comment
OK - you have convinced me. Let's commit it after the release.
-
- removed comment
I agree with Erik. It would have been nice to have this in the release, but it's too late now.
-
- changed status to open
- removed comment
Please apply
-
- removed comment
Ian: don't you want to apply it?
-
reporter - removed comment
Committed in r1511.
-
reporter - changed status to resolved
- removed comment
-
- edited description
- changed status to closed
- Log in to comment
I would be careful with such a change. Given that we still have bugs to fix, and that it may be that not all architectures will be tested again, and that running the test cases doesn't catch all cases how people use the code in production, I would wait until after the release.
Since this is a linker option, should it not be added to LDFLAGS instead of CFLAGS/CXXFLAGS?