* [Bug runtime/11852] New: Nice to have - structure name aliasing/changing
@ 2010-07-29 6:28 Menny_Hamburger at dell dot com
2010-07-29 14:25 ` [Bug runtime/11852] " fche at redhat dot com
` (11 more replies)
0 siblings, 12 replies; 13+ messages in thread
From: Menny_Hamburger at dell dot com @ 2010-07-29 6:28 UTC (permalink / raw)
To: systemtap
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
@ 2010-07-29 14:25 ` fche at redhat dot com
2010-07-29 17:37 ` jistone at redhat dot com
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: fche at redhat dot com @ 2010-07-29 14:25 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
2010-07-29 14:25 ` [Bug runtime/11852] " fche at redhat dot com
@ 2010-07-29 17:37 ` jistone at redhat dot com
2010-08-01 8:05 ` Menny_Hamburger at dell dot com
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jistone at redhat dot com @ 2010-07-29 17:37 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
2010-07-29 14:25 ` [Bug runtime/11852] " fche at redhat dot com
2010-07-29 17:37 ` jistone at redhat dot com
@ 2010-08-01 8:05 ` Menny_Hamburger at dell dot com
2010-08-02 14:18 ` Menny_Hamburger at dell dot com
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Menny_Hamburger at dell dot com @ 2010-08-01 8:05 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
` (2 preceding siblings ...)
2010-08-01 8:05 ` Menny_Hamburger at dell dot com
@ 2010-08-02 14:18 ` Menny_Hamburger at dell dot com
2010-08-02 16:03 ` fche at redhat dot com
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Menny_Hamburger at dell dot com @ 2010-08-02 14:18 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
` (3 preceding siblings ...)
2010-08-02 14:18 ` Menny_Hamburger at dell dot com
@ 2010-08-02 16:03 ` fche at redhat dot com
2010-08-03 6:12 ` Menny_Hamburger at dell dot com
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: fche at redhat dot com @ 2010-08-02 16:03 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
` (4 preceding siblings ...)
2010-08-02 16:03 ` fche at redhat dot com
@ 2010-08-03 6:12 ` Menny_Hamburger at dell dot com
2010-08-03 11:35 ` fche at redhat dot com
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Menny_Hamburger at dell dot com @ 2010-08-03 6:12 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
` (5 preceding siblings ...)
2010-08-03 6:12 ` Menny_Hamburger at dell dot com
@ 2010-08-03 11:35 ` fche at redhat dot com
2010-08-03 11:48 ` Menny_Hamburger at dell dot com
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: fche at redhat dot com @ 2010-08-03 11:35 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
` (6 preceding siblings ...)
2010-08-03 11:35 ` fche at redhat dot com
@ 2010-08-03 11:48 ` Menny_Hamburger at dell dot com
2010-08-03 11:58 ` fche at redhat dot com
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: Menny_Hamburger at dell dot com @ 2010-08-03 11:48 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
` (7 preceding siblings ...)
2010-08-03 11:48 ` Menny_Hamburger at dell dot com
@ 2010-08-03 11:58 ` fche at redhat dot com
2010-08-03 12:01 ` Menny_Hamburger at dell dot com
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: fche at redhat dot com @ 2010-08-03 11:58 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
` (8 preceding siblings ...)
2010-08-03 11:58 ` fche at redhat dot com
@ 2010-08-03 12:01 ` Menny_Hamburger at dell dot com
2010-08-03 12:06 ` fche at redhat dot com
2010-08-08 9:20 ` Menny_Hamburger at dell dot com
11 siblings, 0 replies; 13+ messages in thread
From: Menny_Hamburger at dell dot com @ 2010-08-03 12:01 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
` (9 preceding siblings ...)
2010-08-03 12:01 ` Menny_Hamburger at dell dot com
@ 2010-08-03 12:06 ` fche at redhat dot com
2010-08-08 9:20 ` Menny_Hamburger at dell dot com
11 siblings, 0 replies; 13+ messages in thread
From: fche at redhat dot com @ 2010-08-03 12:06 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug runtime/11852] Nice to have - structure name aliasing/changing
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
` (10 preceding siblings ...)
2010-08-03 12:06 ` fche at redhat dot com
@ 2010-08-08 9:20 ` Menny_Hamburger at dell dot com
11 siblings, 0 replies; 13+ messages in thread
From: Menny_Hamburger at dell dot com @ 2010-08-08 9:20 UTC (permalink / raw)
To: systemtap
------- 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-08-08 9:20 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-29 6:28 [Bug runtime/11852] New: Nice to have - structure name aliasing/changing Menny_Hamburger at dell dot com
2010-07-29 14:25 ` [Bug runtime/11852] " fche at redhat dot com
2010-07-29 17:37 ` jistone at redhat dot com
2010-08-01 8:05 ` Menny_Hamburger at dell dot com
2010-08-02 14:18 ` Menny_Hamburger at dell dot com
2010-08-02 16:03 ` fche at redhat dot com
2010-08-03 6:12 ` Menny_Hamburger at dell dot com
2010-08-03 11:35 ` fche at redhat dot com
2010-08-03 11:48 ` Menny_Hamburger at dell dot com
2010-08-03 11:58 ` fche at redhat dot com
2010-08-03 12:01 ` Menny_Hamburger at dell dot com
2010-08-03 12:06 ` fche at redhat dot com
2010-08-08 9:20 ` Menny_Hamburger at dell dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).