| Summary: | opcontrol --image=.. set invalid if external binary is chosen (using absolute path) | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Severin Gehwolf <sgehwolf> |
| Component: | LinuxTools | Assignee: | OProfile Inbox <linux.oprofile-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | kksebasti, sgehwolf |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
I found this from not long ago : BZ # 296228 . This should be fixed in 0.5.1 (and i can confirm it works at the very least, in trunk) Tested out this functionality with eclipse oprofile from the 0.8.0 update site and was able to profile a binary outside the workspace. Roland, please set the Target Milestone to something reasonable for when this was fixed. If you can't figure it out, just leave it as --- :) Thanks. |
The use case is a bit weird, but if I do the following: 1. Create an empty C++ project 2. Run => Profile Configurations 3. Create a new Oprofile run config 4. Set path where it says "C++ Application" ("Main" tab) to something like /path/to/some/external/binary/which/actually/exists 5. This gets according to .oprofile/daemonrc translated to /path/to/workspace/projectname//path/to/some/external/binary/which/actually/exists Expected result: Do not use project relative path in that case Observed behaviour: Uses path relative to project (although path starts with "/") IMO this doesn't seem to be what one expects. Thoughts?