1:40 a.m.
Hi,
as elfutils package is going to contain unwinder in its next release orphaning
the libunwind library.
https://admin.fedoraproject.org/pkgdb/acls/name/libunwind
Jan
5:23 a.m.
Won't you need to retire it when elfutils obsoletes it?
On 24 November 2012 07:40, Jan Kratochvil <jan.kratochvil(a)redhat.com> wrote:
Hi,
as elfutils package is going to contain unwinder in its next release orphaning
the libunwind library.
https://admin.fedoraproject.org/pkgdb/acls/name/libunwind
Jan
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Mat Booth
http://fedoraproject.org/get-fedora
6:14 a.m.
On Mon, 26 Nov 2012 12:23:16 +0100, Mat Booth wrote:
Won't you need to retire it when elfutils obsoletes it?
The development is not yet at that point, it may happen later:
(1) elfutils needs to integrate it and get released first (January/February),
being worked on with Mark Wielaard:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-November/thr...
$ repoquery -q --whatrequires libunwind --archlist x86_64
libunwind-devel-0:1.0.1-4.fc18.x86_64
perf-0:3.7.0-0.rc6.git4.1.fc19.x86_64
gperftools-libs-0:2.0-7.fc18.x86_64
(2) perf is being actively ported from libunwind API to elfutils API
with Jiri Olsa; but it is also not upstreamed yet:
git://git.jankratochvil.net/linux
unwind4-fix-cache
(3) gperftools is using libunwind API, so far I did not plan to port it
myself, I could later after the projects above get completed.
Jan
7 a.m.
On Mon, Nov 26, 2012 at 7:14 AM, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
On Mon, 26 Nov 2012 12:23:16 +0100, Mat Booth wrote:
> Won't you need to retire it when elfutils obsoletes it?
The development is not yet at that point, it may happen later:
(1) elfutils needs to integrate it and get released first (January/February),
being worked on with Mark Wielaard:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-November/thr...
$ repoquery -q --whatrequires libunwind --archlist x86_64
libunwind-devel-0:1.0.1-4.fc18.x86_64
perf-0:3.7.0-0.rc6.git4.1.fc19.x86_64
gperftools-libs-0:2.0-7.fc18.x86_64
(2) perf is being actively ported from libunwind API to elfutils API
with Jiri Olsa; but it is also not upstreamed yet:
git://git.jankratochvil.net/linux
unwind4-fix-cache
So are you not orphaning libunwind until that is merged into the
upstream kernel?
What about perf releases that support libunwind in older Fedora
releases? Will you wait until all of those have been rebased?
If perf winds up getting stuck relying on an orphaned library for some
non-trivial amount of time, 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.
josh
8:22 a.m.
On Mon, 26 Nov 2012 14:00:17 +0100, Josh Boyer wrote:
So are you not orphaning libunwind until that is merged into the
upstream kernel?
To get the terminology right:
I am 'orphaning' it now. Later it may be 'obsolsted'.
If I should keep it formally maintaining I could. But factically it won't
change what I really do with the libunwind package. I have not fixed any
libunwind bug since 2009 and there is no one filed in RH BZ now; except
https://bugzilla.redhat.com/show_bug.cgi?id=863781
rebase to 1.1 which I do not find meaningful for Fedora anymore, at least not
from my perspective.
I know about too many bugs in libunwind and I have found it easier to rather
reimplement the remaining few bits of elfutils so that elfutils can unwind on
its own.
What about perf releases that support libunwind in older Fedora
releases? Will you wait until all of those have been rebased?
As I said I have not fixed anything in libunwind for the past 3 years and also
I have even never found the non-ia64 part of libunwind meaningful before.
I can write my name into pkgdb ownership field back if you wish so.
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.
Jan
8:27 a.m.
On Mon, 26 Nov 2012 15:22:08 +0100, Jan Kratochvil wrote:
On Mon, 26 Nov 2012 14:00:17 +0100, Josh Boyer wrote:
> So are you not orphaning libunwind until that is merged into the
> upstream kernel?
To get the terminology right:
I am 'orphaning' it now. Later it may be 'obsolsted'.
Probably rather:
I am 'orphaning' it now. Later it may be 'deprecated'.
8:29 a.m.
On Mon, Nov 26, 2012 at 03:22:08PM +0100, Jan Kratochvil wrote:
On Mon, 26 Nov 2012 14:00:17 +0100, Josh Boyer wrote:
> So are you not orphaning libunwind until that is merged into the
> upstream kernel?
To get the terminology right:
I am 'orphaning' it now. Later it may be 'obsolsted'.
If I should keep it formally maintaining I could. But factically it won't
change what I really do with the libunwind package. I have not fixed any
libunwind bug since 2009 and there is no one filed in RH BZ now; except
https://bugzilla.redhat.com/show_bug.cgi?id=863781
rebase to 1.1 which I do not find meaningful for Fedora anymore, at least not
from my perspective.
I know about too many bugs in libunwind and I have found it easier to rather
reimplement the remaining few bits of elfutils so that elfutils can unwind on
its own.
> What about perf releases that support libunwind in older Fedora
> releases? Will you wait until all of those have been rebased?
As I said I have not fixed anything in libunwind for the past 3 years and also
I have even never found the non-ia64 part of libunwind meaningful before.
I can write my name into pkgdb ownership field back if you wish so.
> 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
CCing Arnaldo
jirka
8:34 a.m.
On Mon, Nov 26, 2012 at 9:29 AM, Jiri Olsa <jolsa(a)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.
josh
8:41 a.m.
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(a)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
josh
9 a.m.
On Mon, Nov 26, 2012 at 9:41 AM, Jiri Olsa <jolsa(a)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 <jolsa(a)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
9:07 a.m.
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(a)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 <jolsa(a)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.
ok, no problem with that..
jirka
4:44 p.m.
On Mon, 26.11.12 11:23, Mat Booth (fedora(a)matbooth.co.uk) wrote:
On 24 November 2012 07:40, Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
> Hi,
>
> as elfutils package is going to contain unwinder in its next release orphaning
> the libunwind library.
>
> https://admin.fedoraproject.org/pkgdb/acls/name/libunwind
Hmm, libunwind can now unwind coredumps. Can elfutils do that too?
Lennart
--
Lennart Poettering - Red Hat, Inc.
7:48 p.m.
On Nov 26, 2012 8:22 AM, "Jan Kratochvil" <jan.kratochvil(a)redhat.com>
wrote:
On Mon, 26 Nov 2012 14:00:17 +0100, Josh Boyer 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.
It is somewhat common but not really what we want by design. There's an
inherent race between something being orphaned and getting it out of the
repositories.
*once a package has been released for users we have no way to remove it.
So, at present you could get rid of this for f18+ but we'd keep it for f17
and less even if it was orphaned.
* we retire orphaned packages and block them from the repositories once a
cycle. But if you orphan the package after we do that for this cycle it
will not get blocked unless you explicitly request it.
But these are just implementation. Ideally we want every package that gets
released to the users to have a maintainer that is watching bug reports and
attempting to fix anything serious.
So if you know you aren't going to fix bugs for this package in f19, the
best answer is to block this package from f19 and get those packages that
currently depend on it to stop doing so (by disabling features or porting
to something else.) (And not necessarily in that order.) If you wanted to
do this for f18 as well it might be a little late since it's something that
requires cooperation with multiple packages.
Toshio
12:51 a.m.
On Mon, 26 Nov 2012 23:44:24 +0100, Lennart Poettering wrote:
On Mon, 26.11.12 11:23, Mat Booth (fedora(a)matbooth.co.uk) wrote:
> On 24 November 2012 07:40, Jan Kratochvil <jan.kratochvil(a)redhat.com> wrote:
> > Hi,
> >
> > as elfutils package is going to contain unwinder in its next release orphaning
> > the libunwind library.
> >
> > https://admin.fedoraproject.org/pkgdb/acls/name/libunwind
Hmm, libunwind can now unwind coredumps. Can elfutils do that too?
Yes:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-November/002...
+/* Get innermost frame of first thread of core file COREFILE. Returns NULL on
+ failure. */
+extern Dwfl_Frame_State *dwfl_frame_state_core (Dwfl *dwfl,
+ const char *corefile);
Tested on core files generated in tests/run-backtrace.sh.
For non-x86* there are testcases (also via tests/run-backtrace.sh):
https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-November/002...
* backtrace.ppc.core.bz2: New file.
* backtrace.ppc.exec.bz2: New file.
* backtrace.ppc64.core.bz2: New file.
* backtrace.ppc64.exec.bz2: New file.
* backtrace.s390.core.bz2: New file.
* backtrace.s390.exec.bz2: New file.
* backtrace.s390x.core.bz2: New file.
* backtrace.s390x.exec.bz2: New file.
Jan
1:01 a.m.
On Tue, 27 Nov 2012 02:48:00 +0100, Toshio Kuratomi wrote:
But these are just implementation. Ideally we want every package
that gets
released to the users to have a maintainer that is watching bug reports and
attempting to fix anything serious.
There are serious bugs so that some cases are not properly unwound but nobody
has reported it in Fedora BZ yet. And one of the reasons of the elfutils
extension was exactly to fix it.
I understand the formal rules in this case. But do you think I will be fixing
known bugs in libunwind which were the reason I wrote the elfutils extension?
Maybe we should make a difference between functionality of the package
(unwinding) and its packaging; there may happen some issues with packaging
which are easy to fix in general and which I can do. I have taken the
ownership back but (a) only for the packaging kind of bugs and
(b) only for f16+f17+f18, not for f19.
So if you know you aren't going to fix bugs for this package in
f19, the
best answer is to block this package from f19 and get those packages that
currently depend on it to stop doing so (by disabling features or porting
to something else.)
gperftools remains unsolved in this regard. I do not know more about it now.
Thanks,
Jan
6:23 p.m.
Josh Boyer wrote:
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.
And I don't see a reason not to. The update to 3.8 will switch to the
supported library and we will be all set. So there's no point in disabling
the feature in 3.7.
Kevin Kofler
4148
days inactive
4164
days old
15 comments
7 participants
participants (7)
-
Jan Kratochvil -
Jiri Olsa -
Josh Boyer -
Kevin Kofler -
Lennart Poettering -
Mat Booth -
Toshio Kuratomi