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

["Menny_Hamburger at dell dot com" <sourceware-bugzilla at sourceware dot org>]

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