On Mon, Nov 26, 2012 at 10:00:52AM -0500, Josh Boyer wrote: > 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. ok, no problem with that.. jirka -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
