[petsc-dev] PETSc-3.4 PR open at https://github.com/Homebrew/homebrew-science/pull/343
Jed Brown
jedbrown at mcs.anl.gov
Sat Oct 12 17:10:25 CDT 2013
Aron Ahmadia <aron at ahmadia.net> writes:
> On Sat, Oct 12, 2013 at 5:18 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>> It would be nice to have a
>> systematic (or at least recommended) place to put that debug library.
>
> /usr/lib/debug
>
> Is standard in Fedora and Debian, good enough for me.
Oh, this is just a place for an identical library built using -O0 -g?
> Here's an interesting discussion on Debian on where this is going in
> the future (automated creation of debug libraries):
> https://wiki.debian.org/AutomaticDebugPackages
>
> PETSc is in an interesting situation because the package itself has
> different levels of "optimizations". If I recall correctly, the input
> validation only adds overhead on the order of 5%. I'd suggest leaving
> that in to a prefix build, then stripping/splitting symbols into a
> debug library, as the rest of the open source world seems to be doing.
I was broadly including things like walking the heap to check that all
sentinels are intact after each function evaluation. It's actually big
overhead, and when combined with the difference between -O2 and -O0,
amounts to 5x or more. Our debug builds also affect some macros in the
headers that users may be using. For example, PetscFunctionBegin /
PetscFunctionReturn logs a stack so that PETSc's signal handler can
provide a stack trace (without assistance of a debugger).
Debugging symbols are much more about disk space than performance.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131012/8d652e3a/attachment.sig>
More information about the petsc-dev
mailing list