[Bug runtime/11852] Nice to have - structure name aliasing/changing

[Menny_Hamburger at dell dot com]

------- Additional Comments From Menny_Hamburger at dell dot com  2010-08-03 06:11 -------
I added both options to the same probe statement.
The first option works and does not break anything.
The second option gives me:
semantic error: type definition 'pmaplist<rpc/pmap_prot.h>' not found: 
identifier '@cast' at ./portmap3.stp:70:37
        source:         println("pml->pml_map.pm_prog = ", @cast
($pml,"pmaplist<rpc/pmap_prot.h>")->pml_map->pm_prog)

So although The Guru mode option works, in this case there is no need to use 
it. 
As I see it there are several issues here:
1) In which cases is GURU mode required?
2) When it is required, when does the method I suggested break?
3) Can this method be standarized in any way?

Regarding (2), my take is that the method would break in the following 
situations:
(a) Different structure definitions between .../include/linux 
and /usr/include - this looks realtively simple to handle by renaming and 
perhaps the aliasing enhancment I suggested.
(b) The compilation flags of the user application may need to be added to the 
command line; they can include options that conflict with the kernel build 
options. The most extreme issue I can see here is when the user application is 
compiled with -m32 over x86_64. I have an idea how to go over this, but it's 
needs some thinking.

Thnx




-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11852

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.