Bug 9866 - save_stack_trace code in runtime stack* needs more than CONFIG_STACKTRACE
Summary: save_stack_trace code in runtime stack* needs more than CONFIG_STACKTRACE
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: runtime (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Tim Moore
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-18 22:31 UTC by Frank Ch. Eigler
Modified: 2009-03-04 12:27 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2009-02-18 22:31:46 UTC 
The API in linux/stacktrace.h has drifted somewhat.  If
the runtime is to retain compatibility with RHEL5-era 2.6.18,
autoconf- or KERNEL_VERSION-based checks are needed.

Related, dump_trace() does not seem necessary as we can
also invoke address->symbol-name mappings in the runtime
proper.
Comment 1 Frank Ch. Eigler 2009-02-28 20:43:26 UTC 
Part of the responsibility of committing code to the runtime
is keeping it buildable as kernels change.
Comment 2 Srikar Dronamraju 2009-03-04 10:15:52 UTC 
Even with commit 8aaa6e11f666ad372107299b5b17602011125c7d
"PR9866 band-aid: deactivate new CONFIG_STACKTRACE code for older kernels"

Stap fails to build a kernel module on a ppc64 machine with latest kernel with
config option CONFIG_STACKTRACE set.

This is because there is no asm/stacktrace.h file for ppc64 and 
hence we cant use struct stacktrace_ops print_stack_ops on ppc64.
Comment 3 Tim Moore 2009-03-04 12:27:37 UTC 
Fixed by adding a STAPCONF test and define (8c5905d0)