Bug 1145 - make systemtap support cross-debugging
Summary: make systemtap support cross-debugging
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P1 normal
Target Milestone: month
Assignee: Frank Ch. Eigler
URL:
Keywords:
Depends on: 2208
Blocks: 2035
  Show dependency treegraph
 
Reported: 2005-08-01 17:17 UTC by Frank Ch. Eigler
Modified: 2006-11-15 20:27 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed: 2005-08-19 19:13:44


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2005-08-01 17:17:35 UTC
- includes respecting of the "-R <version" string from stap command line
- includes no longer performing translation-time queries of system
module/program addresses; instead using install-time tokens that module_init can
compute/verify
Comment 1 Roland McGrath 2005-08-19 19:13:44 UTC
I have figured out the plan for this.  Some implementation work still to be
done, not really scheduled yet.
Comment 2 Roland McGrath 2005-08-25 18:10:28 UTC
The elfutils support for this is done.
Comment 3 Frank Ch. Eigler 2005-09-28 15:40:56 UTC
With cross-instrumentation, the generated code will need to emit a variety of
self-defense checks against kernel version, module loading state, etc.  For
example, including an explicit "uname -r" match assertion from build to run time
would be good.
Comment 4 Graydon Hoare 2005-12-21 00:55:52 UTC
I haven't looked into this extensively, but my guess is that it requires:

 - different include paths when pulling in stap libraries
 - some target-specific rather than host-specific defines in the 
   runtime and generated code
 - turning off the pin-a-module-while-compiling code in dwarf_derived_probe
   constructor
 - some command-line UI to do save the probe module aside after compiling
 - and some more UI to handle starting stapd on a pre-build probe module
 - opening dwfl using a different module set, in dwflpp::setup
Comment 5 William Cohen 2006-08-17 19:00:26 UTC
When the perfmon support is integrated into systemtap there will be some need to
check that the processor architecture matches up between the host and target.

Unlike oprofile, libpfm doesn't have concept of generating events and
performance monitoring configuration for anything other than the host machine.
Thus, for the time being only a check that the host and target match up rather
than an flag to select the appropriate architecture.
Comment 6 Frank Ch. Eigler 2006-11-15 20:27:55 UTC
This part (run-time address relocations) is done.