On Mon, Nov 26, 2012 at 9:41 AM, Jiri Olsa <jolsa@xxxxxxxxxx> 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 <jolsa@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
