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

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

[Menny_Hamburger at dell dot com]

I do not know if this belongs to the runtime or elsewhere:
When probing a user application or library that includes structure names 
simmilar to one defined in the kernel, it would be nice to be able to rename 
the structure (only for that specific app) in order to prevent redefinition 
compilation errors, for example:
I am currently trying to tap Samba, which requires some work by itself (many 
conflicting types between /usr/include/...
Samba has a user_struct, thus compilation fails due to redefinitions of 
user_struct in Samba and in the kernel. It would be nice to be able to have an 
alias or to be able to change the structure name while probing.

-- 
           Summary: Nice to have - structure name aliasing/changing
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: Menny_Hamburger at dell dot com


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.

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

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-07-29 14:25 -------
Could you attach the script and the errors?  In general, type names
are resolved on a per-compilation-unit basis, so kernel types should
not collide with user-space types at all.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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.

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

[jistone at redhat dot com]

------- Additional Comments From jistone at redhat dot com  2010-07-29 17:37 -------
My hunch is that this would only be an issue if you were trying to #include a
userspace header in a %{ %} embedded-c block, which we can't support.  All of
the systemtap code is compiled in the kernel build environment.  The only way to
access user structures is either through $var->foo accesses or through @cast'ing
with headers.

-- 


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.

[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-01 08:05 -------
Regarding your'e second comment, I hacked and it seems to be working:
1) I have generated an alternate path for include 
(/usr/src/debug/usr/include), which includes all the headers with conflicts.
2) When there is a conflict the .h file in the alternate directory was 
modified to ifdef out the typedef/structure name.
3) An activation script sets -B cflags where the CFLAGS includes all the 
necassary ifdefs according to the modifications in (2). 
I also added -fno-common and mcmodel=kernel to the CFLAGS.
In addition, C_INCLUDE_PATH was modified to take the alternate include path 
before /usr/include.
4) In Samba I changed:
   user_struct -> smb_user_struct
   bitmap_copy -> smb_bitmap_copy
   timeval_compare -> smb_timeval_compare
   timespec_compare -> smb_timespec_compare.



Taking into account that the problematic typedefs in the kernel are the same 
as those in /usr/include (when they are not there is no problem to rename 
them) - this will (does) work: I included Samba includes inside %% and managed 
to probe an internal Samba structure using copy_to_user/get_user semantics.

I realize this is a hack, but I cannot see a flaw in my logic.
If there is an inherant reason for this not to work I would like to know about 
it before I do aditional harm. If not - why not support this type of work in 
addition to systemtap-sdc-devel way of adding marks inside the code.

Best Reagrds,
Menny



(In reply to comment #2)
> My hunch is that this would only be an issue if you were trying to #include a
> userspace header in a %{ %} embedded-c block, which we can't support.  All of
> the systemtap code is compiled in the kernel build environment.  The only 
way to
> access user structures is either through $var->foo accesses or through 
@cast'ing
> with headers.

(In reply to comment #2)
> My hunch is that this would only be an issue if you were trying to #include a
> userspace header in a %{ %} embedded-c block, which we can't support.  All of
> the systemtap code is compiled in the kernel build environment.  The only 
way to
> access user structures is either through $var->foo accesses or through 
@cast'ing
> with headers.



-- 


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.

[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-02 14:18 -------
Created an attachment (id=4893)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4893&action=view)
Example script for probing portmap after removing type conflicts


-- 


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.

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

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-08-02 16:03 -------
Menny, what breaks if you try

probe process("/sbin/portmap").statement(...) {
   println("...", $pml->pml_map->pm_prog)
   println("...", $pml->pml_map->pm_vers)
}
etc.?

Or perhaps

   println("...", @cast($pml,"pmaplist<rpc/pmap_prot.h>")->pml_map->pm_prog)

?

-- 


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.

[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.

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

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-08-03 11:35 -------
> I added both options to the same probe statement.
> The first option works and does not break anything.

Great, that should be the first method we anticipated a stap user would try it.

> The second option gives me:
> semantic error: type definition 'pmaplist<rpc/pmap_prot.h>' not found: 
> identifier '@cast' at ./portmap3.stp:70:37

OK, you must be running a version of systemtap from 2009.  A newer one
should give you this facility.

> As I see it there are several issues here:
> 1) In which cases is GURU mode required?

Mainly when you require access to data that there is no other way
to get to; or when accessing it requires complex kernel interaction
such as locks or kernel API calls.

> 2) When it is required, when does the method I suggested break?

The basic problem is as Josh stated: embedded-C code runs in kernel
space and is thus compiled against kernel headers with kernel
assumptions.  There are many different assumptions in kernel space
beyond a different namespace of struct types.  Usage of floats,
struct padding, argument passing ABIs are just a few that come to mind.

> 3) Can this method be standardized in any way?

If the script-language-level constructs ($foo->bar, @cast()) are truly
not sufficient for a real scenario, we can try harder to figure it out.


-- 


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.

[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 11:47 -------
Frank,

For the meantime using @cast functionality suits my needs:
I am leading the systemtap initiative here for use by other developers over 
components other then the kernel - so such functionality is like killing a fly 
with a sledge hammer. 

The version I am using is 1.1-3.el5 from RHEL5.5, which has problems with 
casts. I will forward the request to upgrade into a higher version to my 
acquantances at RedHat. 

Best Regards,
Menny
 

-- 


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.

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

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-08-03 11:58 -------
> For the meantime using @cast functionality suits my needs:
> I am leading the systemtap initiative here for use by other developers over 
> components other then the kernel - so such functionality is like killing a fly 
> with a sledge hammer. 

Yeah, especially if you are tempted toward the dark arts of %{ %}.

> The version I am using is 1.1-3.el5 from RHEL5.5, which has problems with 
> casts. I will forward the request to upgrade into a higher version to my 
> acquaintances at RedHat.

https://bugzilla.redhat.com/show_bug.cgi?id=606726

(In the mean time, you can build your own stap from the public source
releases; it will work fine on RHEL5).

Shall we CLOSED/WONTFIX this specific type-renaming proposal for now?

-- 


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.

[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 12:01 -------
let's!!

It's been a plessure.

M.

-- 


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.

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

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-08-03 12:06 -------
Perhaps we'll reopen someday if @cast etc. just aren't up to the job.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WONTFIX


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.

[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-08 09:20 -------
As I said the %{ %} are not include in myfile.h - I used to have this type 
declaration inside the script and I send you that by mistake.

I ran this on systemtap 1.3-2 from fedora.
There are no gcc erros - just seems /tmp/myfile.h (or from any other location) 
is not parsed although I see that it is included (-i </tmp/myfile.h>).



-- 


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.