Ryan Lewis wrote:
> I'm proposing that we consider a new type of extra software package:
> foo-profile. This
> package would be close to a "release" build of software, but, would
> have options such as
> "-fno-emit-frame-pointer" enabled.
>
> Having stack frame pointers enabled within libraries is extremely
> valuable for profiling.
> When you have complex scientific codes it can be challenging to
> pinpoint from where the symbol
> __pthread_cond_wait is being hit the most from. On the other hand
> using a debug compilation
> means that you can't be sure that you are profiling something at all
> similar to what happens when
> you enable optimizations.
>
> Thoughts?
That's not reasonable at all, as it'd double the build efforts for every
Fedora package.
You have to know that we also DO NOT build separate debug and release
builds. We build our packages once, with optimization enabled and with
debugging information. Then RPM runs a tool called eu-strip which separates
the stripped executable from the debugging information: The stripped
executable ends up in the main package or some subpackage, the debugging
information ends up in the -debuginfo package. There are no debug binaries,
only stripped binaries and separate debuginfo files (which, together, are
equivalent to a binary with debugging information included).
As for backtraces with frame pointers omitted, that's what unwinding
information (part of the debugging information we generate) is for. GCC and
GDB have made a lot of progress on allowing to debug optimized binaries (and
for the special case of unwinding, unwinding libraries such as libunwind
should work fine with unwinding information and without frame pointer too).
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
