On Mon, Nov 26, 2012 at 9:41 AM, Jiri Olsa <jo...@redhat.com> wrote: > On Mon, Nov 26, 2012 at 09:34:35AM -0500, Josh Boyer wrote: >> On Mon, Nov 26, 2012 at 9:29 AM, Jiri Olsa <jo...@redhat.com> wrote: >> >> > If perf winds up getting stuck relying on an orphaned library for some >> >> > non-trivial amount of time, >> >> >> >> AFAIK that is common in Fedora there are orphaned libraries in use for >> >> a release or two. >> >> >> >> >> >> > I'd rather just turn off libunwind support in perf now. It's only >> >> > enabled >> >> > in rawhide at the moment because it is a 3.7 feature. Before we bring >> >> > 3.7 >> >> > back to f17-f18, we should probably decide. >> >> >> >> That is more a question to Jiri Olsa, the author of perf libunwind client. >> > >> > it will be configurable for both libunwind and elfutils unwinders, >> > and making default the one with better results or available >> > >> > I should send upstream perf changes within this week >> >> Those won't make it into the kernel until 3.8 though. So for 3.7, I'm >> thinking we should just disable perf libunwind support entirely. Once >> elf-utils gets its unwinder and the patches for perf hit rawhide we can >> turn it back on. > > currently if the libunwind is not found during build time, it's not compiled > in
Yes, I'm aware of that. At the moment, it is found because the library is in Fedora. However, I don't want to build 3.7 perf against a library that is orphaned and clearly not really supported. So I'm going to disable it with NO_LIBUNWIND=1 and we can revisit perf with unwind support for the 3.8 kernel when elf-utils is ready. Basically, if something better is going to come along the next version then I really don't see a reason to ship the already obsolete and orphaned support today. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
