2013-09-13 17:09:08

by Jean Pihet

[permalink] [raw]
Subject: [PATCH] perf tools: Check libunwind for availability of dwarf parsing feature

The newly added dwarf unwinding feature [1] requires:
. a recent version (>= 1.1) of libunwind,
. libunwind to be configured with --enable-debug-frame.

[1] http://www.spinics.net/lists/kernel/msg1598951.html

Add the corresponding API test in the feature check list.

Signed-off-by: Jean Pihet <[email protected]>
---
tools/perf/config/feature-tests.mak | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/perf/config/feature-tests.mak b/tools/perf/config/feature-tests.mak
index 708fb8e..87124d0 100644
--- a/tools/perf/config/feature-tests.mak
+++ b/tools/perf/config/feature-tests.mak
@@ -176,14 +176,23 @@ extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as,
unw_proc_info_t *pi,
int need_unwind_info, void *arg);

-
#define dwarf_search_unwind_table UNW_OBJ(dwarf_search_unwind_table)

+extern int
+UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug,
+ unw_word_t ip,
+ unw_word_t segbase,
+ const char *obj_name, unw_word_t start,
+ unw_word_t end);
+
+#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame)
+
int main(void)
{
unw_addr_space_t addr_space;
addr_space = unw_create_addr_space(NULL, 0);
unw_init_remote(NULL, addr_space, NULL);
+ dwarf_find_debug_frame(0, NULL, 0, 0, NULL, 0, 0);
dwarf_search_unwind_table(addr_space, 0, NULL, NULL, 0, NULL);
return 0;
}
--
1.8.1.2


2013-09-13 17:15:47

by Will Deacon

[permalink] [raw]
Subject: Re: [PATCH] perf tools: Check libunwind for availability of dwarf parsing feature

Hi Jean,

On Fri, Sep 13, 2013 at 06:08:41PM +0100, Jean Pihet wrote:
> The newly added dwarf unwinding feature [1] requires:
> . a recent version (>= 1.1) of libunwind,
> . libunwind to be configured with --enable-debug-frame.
>
> [1] http://www.spinics.net/lists/kernel/msg1598951.html
>
> Add the corresponding API test in the feature check list.

Any reason not to merge this in with the third patch in original series? I
don't think it's been picked up by anybody yet, so it would make sense to
repost with this fixup after the merge window.

Will

2013-09-13 17:19:08

by Jean Pihet

[permalink] [raw]
Subject: Re: [PATCH] perf tools: Check libunwind for availability of dwarf parsing feature

Hi Will,

On 13 September 2013 19:15, Will Deacon <[email protected]> wrote:
> Hi Jean,
>
> On Fri, Sep 13, 2013 at 06:08:41PM +0100, Jean Pihet wrote:
>> The newly added dwarf unwinding feature [1] requires:
>> . a recent version (>= 1.1) of libunwind,
>> . libunwind to be configured with --enable-debug-frame.
>>
>> [1] http://www.spinics.net/lists/kernel/msg1598951.html
>>
>> Add the corresponding API test in the feature check list.
>
> Any reason not to merge this in with the third patch in original series? I
> don't think it's been picked up by anybody yet, so it would make sense to
> repost with this fixup after the merge window.
Yes you are right
Will repost with this patch folded into the third patch, or as a
fourth patch. Any preference?

Thx,
Jean

>
> Will

2013-09-14 06:02:31

by Ingo Molnar

[permalink] [raw]
Subject: Re: [PATCH] perf tools: Check libunwind for availability of dwarf parsing feature


* Jean Pihet <[email protected]> wrote:

> Hi Will,
>
> On 13 September 2013 19:15, Will Deacon <[email protected]> wrote:
> > Hi Jean,
> >
> > On Fri, Sep 13, 2013 at 06:08:41PM +0100, Jean Pihet wrote:
> >> The newly added dwarf unwinding feature [1] requires:
> >> . a recent version (>= 1.1) of libunwind,
> >> . libunwind to be configured with --enable-debug-frame.
> >>
> >> [1] http://www.spinics.net/lists/kernel/msg1598951.html
> >>
> >> Add the corresponding API test in the feature check list.
> >
> > Any reason not to merge this in with the third patch in original series? I
> > don't think it's been picked up by anybody yet, so it would make sense to
> > repost with this fixup after the merge window.
>
> Yes you are right Will repost with this patch folded into the third
> patch, or as a fourth patch. Any preference?

I suspect it should be a separate patch, but _prior_ the patch that makes
use of this new facility.

That way it's bisection-safe.

Thanks,

Ingo