[Bug translator/1155] inline functions

[Bug translator/1155] inline functions

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-02-13 17:34 -------
A systemtap user reported continued inline problems, in a kernel compiled with
gcc 4.1.  Test case again 2.6.16rc3:

probe kernel.statement("*@kernel/timer.c:464") { printf("%p:%p\n", $fn, $data); }


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|graydon at redhat dot com   |systemtap at sources dot
                   |                            |redhat dot com
             Status|SUSPENDED                   |ASSIGNED


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

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

[Bug translator/1155] inline functions

[dwilder at us dot ibm dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dwilder at us dot ibm dot
                   |                            |com


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

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

[Bug translator/1155] inline functions

[guanglei at cn dot ibm dot com]

------- Additional Comments From guanglei at cn dot ibm dot com  2006-08-09 03:01 -------
I tried i386/gcc 4.1.1/FC5 and ppc64/gcc 3.4.5/RHEL4 with latest
SystemTap/elfutils, both failed to resove the target symbol.

On i386/gcc 4.1.1, GCC compiles away the loc info of all the arguments of
context_switch(), so SystemTap failed to resolve the target symbol.

On ppc64/gcc 3.4.5, although GCC only compiles away the loc info of $rq, but the
loc info of $prev and $next exists. But when I tried to retrieve $prev/$next of
context_switch(), SystemTap still failed to resolve them.

I checked the gcc bug 23551, still not fixed. :-(

-- 


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

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

[Bug translator/1155] inline functions

[jblunck at suse dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jblunck at suse dot de


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

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

[Bug translator/1155] inline functions

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2006-12-09 05:45 -------
There is nothing which GCC can do better really as you want optimizations so we
give you optimizations but you also want exact debugging info, you really cannot
have both.

-- 


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

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

[Bug translator/1155] inline functions

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2006-12-11 14:37 -------
(In reply to comment #5)
> There is nothing which GCC can do better really as you want optimizations so we
> give you optimizations but you also want exact debugging info, you really cannot
> have both.

Andrew, that may be a true general impression, but this scenario deserves more
detailed analysis.


-- 


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

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

[Bug translator/1155] inline function parameters

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2007-03-30 19:26 -------
We are blocked on <http://gcc.gnu.org/PR23551>.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |SUSPENDED
            Summary|inline functions            |inline function parameters


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

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

Packaging systemtap

[John Liang]

HI there,

Is there a way to run the complied module for systemtap? 
Right now, it seems we can only run it as "stap -g <source name>".
Is there a way to run it as "stap -g <module name>"?

The reason is that we do not want to expose the source code
to our customers; we do not want our customer to change the 
source code without our authorization. 

Any comments?

Thanks,
--
John Liang

Re: Packaging systemtap

[Eugene Teo]

John Liang wrote:
> HI there,
> 
> Is there a way to run the complied module for systemtap? 
> Right now, it seems we can only run it as "stap -g <source name>".
> Is there a way to run it as "stap -g <module name>"?

Yes, you can run stap with -k and -m, and save the kernel module. Then on
your customer's machine, make sure it has systemtap-runtime installed, run
staprun -L to load and run the module.

Eugene
-- 
Eugene Teo, RHCE		Red Hat Global Support Services
Phone: +65 6490 4142		GPG ID: 58DF8823

Re: Packaging systemtap

[Martin Hunt]

On Wed, 2007-05-02 at 21:38 +0800, Eugene Teo wrote:
> John Liang wrote:
> > HI there,
> > 
> > Is there a way to run the complied module for systemtap? 
> > Right now, it seems we can only run it as "stap -g <source name>".
> > Is there a way to run it as "stap -g <module name>"?
> 
> Yes, you can run stap with -k and -m, and save the kernel module. Then on
> your customer's machine, make sure it has systemtap-runtime installed, run
> staprun -L to load and run the module.

You probably just want to do "staprun module_name".  "-L" will load the
module and then detach, allowing it to run in the background. You have
to later connect with "staprun -A" to get any output. It should only be
used in special cases.

Martin

Re: Packaging systemtap

[Frank Ch. Eigler]

"John Liang" <jliang@ibrix.com> writes:

> Is there a way to run the complied module for systemtap? 
> [...]

Yes, see http://sources.redhat.com/systemtap/wiki/WScrossCompiling

- FChE

RE: Packaging systemtap

[John Liang]

FChE,

Is there a systemtap-runtime rpm for Redhat 4 update 3? 
I found something for Fedora Core 6. 

Thanks,
--
John Liang

-----Original Message-----
From: fche@redhat.com [mailto:fche@redhat.com] 
Sent: Wednesday, May 02, 2007 2:43 PM
To: John Liang
Cc: systemtap@sources.redhat.com
Subject: Re: Packaging systemtap

"John Liang" <jliang@ibrix.com> writes:

> Is there a way to run the complied module for systemtap? 
> [...]

Yes, see http://sources.redhat.com/systemtap/wiki/WScrossCompiling

- FChE

[Bug translator/1155] inline function parameters

[wcohen at redhat dot com]

------- Additional Comments From wcohen at redhat dot com  2007-05-15 22:08 -------
Created an attachment (id=1841)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1841&action=view)
Cannot find $task local variable for probe point

On the 2.6.21-1.3142.fc7 x86_64 kernel the $task parameter of inline
rpc_release_task() appears to prevent systemtap.samples/lket.stp from
compiling. Get the following message:

$ ../../install/bin/stap -v /tmp/rpc.stp
Pass 1: parsed user script and 54 library script(s) in 1220usr/50sys/1278real
ms.
semantic error: failed to retrieve location attribute for local 'task'
(dieoffset: 0x41513): identifier '$task' at /tmp/rpc.stp:3:22
semantic error: failed to retrieve location attribute for local 'task'
(dieoffset: 0x41513): identifier '$task' at /tmp/rpc.stp:4:24
semantic error: failed to retrieve location attribute for local 'task'
(dieoffset: 0x41513): identifier '$task' at /tmp/rpc.stp:5:24
semantic error: failed to retrieve location attribute for local 'task'
(dieoffset: 0x41513): identifier '$task' at /tmp/rpc.stp:6:24
Pass 2: analyzed script: 1 probe(s), 4 function(s), 1 embed(s), 0 global(s) in
200usr/360sys/553real ms.
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.


-- 


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

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

[Bug translator/1155] inline function parameters

[wcohen at redhat dot com]

------- Additional Comments From wcohen at redhat dot com  2007-05-16 16:56 -------
*** Bug 4510 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wcohen at redhat dot com


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

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

[Bug translator/1155] inline function parameters

[mhiramat at redhat dot com]

------- Additional Comments From mhiramat at redhat dot com  2008-01-02 22:15 -------
What is this status?
Since static functions which called from one place are compiled as
an inline automatically(even if it is not obviously marked as "inline"),
this feature is very important.


-- 


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

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

[Bug translator/1155] inline function parameters

[mhiramat at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |5555
              nThis|                            |


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

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

[Bug translator/1155] inline function parameters

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2008-08-12 20:44 -------
With aoliva's latest gcc var-tracking code, linux 2.6.27-rc2 was compilable,
runnable, and showed some promise with respect to inline function parameters.
For example, this started to work:

 probe kernel.function("context_switch") {println($next)}

However, by printing "$$vars" instead, one can see that the other parameters
are not visible at that place.  Setting a statement probe a few lines down
exposes $prev and a few more locals though, which is a good sign.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at redhat dot com


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

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

[Bug translator/1155] inline function parameters

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2008-09-16 15:37 -------
I believe the following new regressions under 2.6.26.3-29.fc9.x86_64 are also
caused by this:

Running /home/mark/src/systemtap/testsuite/systemtap.examples/check.exp ...
FAIL: systemtap.examples/process/sig_by_pid build
FAIL: systemtap.examples/process/sig_by_pid run
FAIL: systemtap.examples/process/sig_by_proc build
FAIL: systemtap.examples/process/sig_by_proc run
FAIL: systemtap.examples/process/sigkill build
FAIL: systemtap.examples/process/sigkill run
FAIL: systemtap.examples/process/sigmon build
FAIL: systemtap.examples/process/sigmon run

They all fail in the same way:

attempting command  stap -p4 sig_by_pid.stp OUT semantic error: failed to
retrieve location attribute for local 'sig' (dieof fset: 0x4bbda9): identifier
'$sig' at /usr/local/systemtap/share/systemtap/tapse t/signal.stp:92:11 semantic
error: failed to retrieve location attribute for local 't' (dieoffset: 
0x4bbd9f): identifier '$t' at :93:12 semantic error: failed to retrieve location
attribute for local 'sig' (dieoffset : 0x4bbeef): identifier '$sig' at :92:11
semantic error: failed to retrieve location attribute for local 't' (dieoffset:
 0x4bbee5): identifier '$t' at :93:12 semantic error: failed to retrieve
location attribute for local 'sig' (dieoffset : 0x4bd412): identifier '$sig' at
:92:11 semantic error: failed to retrieve location attribute for local 't'
(dieoffset:  0x4bd408): identifier '$t' at :93:12 semantic error: failed to
retrieve location attribute for local 'sig' (dieoffset : 0x4bbda9): identifier
'$sig' at :92:11 

specific_send_sig_info used to be a larger static function in kernel/signal.c,
but in 2.6.26 is just a simple oneliner:

static int
specific_send_sig_info(int sig, struct siginfo *info, struct task_struct *t)
{
        return send_signal(sig, info, t, 0);
}


-- 


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

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

[Bug translator/1155] inline function parameters

[srikar at linux dot vnet dot ibm dot com]

------- Additional Comments From srikar at linux dot vnet dot ibm dot com  2008-11-13 08:35 -------
I have created a bug 7030 as this can be solved by changing the signal.stp and
not wait till the gcc inlining issue is solved.

(In reply to comment #12)

> Running /home/mark/src/systemtap/testsuite/systemtap.examples/check.exp ...
> FAIL: systemtap.examples/process/sig_by_pid build
> FAIL: systemtap.examples/process/sig_by_pid run
> FAIL: systemtap.examples/process/sig_by_proc build
> FAIL: systemtap.examples/process/sig_by_proc run
> FAIL: systemtap.examples/process/sigkill build
> FAIL: systemtap.examples/process/sigkill run
> FAIL: systemtap.examples/process/sigmon build
> FAIL: systemtap.examples/process/sigmon run
> 


-- 


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

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

[Bug translator/1155] inline function parameters

[fche at redhat dot com]

------- Additional Comments From fche at redhat dot com  2010-05-13 16:54 -------
With gcc 4.5 (and partial vta backports in RH gcc 4.4.*), this problem
is more or less history.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|                            |FIXED


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

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