headers
mjw at redhat dot com | 1 Apr 2012 20:26
Favicon

[Bug translator/13934] New: hand-written assembly SDT probes fail to parse

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

             Bug #: 13934
           Summary: hand-written assembly SDT probes fail to parse
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap <at> sourceware.org
        ReportedBy: mjw <at> redhat.com
    Classification: Unclassified

FAIL: sdt_misc asm (0) asm

spawn /usr/local/install/systemtap/bin/stap -c
/usr/local/build/systemtap-obj/te
stsuite/sdt_asm.x /home/mark/src/systemtap/testsuite/systemtap.base/sdt_asm.stp 
/usr/local/build/systemtap-obj/testsuite/sdt_asm.x
WARNING: cannot find module /usr/local/build/systemtap-obj/testsuite/sdt_asm.x
d
ebuginfo: No DWARF information found
semantic error: while resolving probe point: identifier 'process' at
/home/mark/
src/systemtap/testsuite/systemtap.base/sdt_asm.stp:1:7
        source: probe process( <at> 1).mark("a") 
                      ^

semantic error: no match
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mark Wielaard | 1 Apr 2012 20:27
Picon
Favicon

Re: [PATCH v3 1/2] PR13475: Fix ARM SDT_V3 operand parsing

On Wed, Mar 28, 2012 at 07:46:16AM -0700, Wade Farnsworth wrote:
> * Include regular expressions to parse ARM operands
> * Add ARM register data
> * Allow for whitespace in ARM operands containing []'s
> 
> Signed-off-by: Wade Farnsworth <wade_farnsworth <at> mentor.com>
> ---
>  tapsets.cxx |   80 +++++++++++++++++++++++++++++++++++++++++++++++-----------
>  1 files changed, 65 insertions(+), 15 deletions(-)
> 
> diff --git a/tapsets.cxx b/tapsets.cxx
> index ccabc67..97cedc0 100644
> --- a/tapsets.cxx
> +++ b/tapsets.cxx
>  <at>  <at>  -6269,10 +6321,8  <at>  <at>  sdt_query::setup_note_probe_entry (int type, const char *data, size_t len)
>  
>    arg_count = 0;
>    for (unsigned i = 0; i < arg_string.length(); i++)
> -    if (arg_string[i] == ' ')
> +    if (arg_string[i] == ' <at> ')
>        arg_count += 1;
> -  if (arg_string.length() != 0)
> -    arg_count += 1;
>    

This part of the patch causes the following regression:
FAIL: sdt_misc asm (0) asm

spawn /usr/local/install/systemtap/bin/stap -c /usr/local/build/systemtap-obj/te
stsuite/sdt_asm.x /home/mark/src/systemtap/testsuite/systemtap.base/sdt_asm.stp
(Continue reading)

Permalink | Reply | 0 comments |
headers
mjw at redhat dot com | 1 Apr 2012 20:28
Favicon

[Bug translator/13934] hand-written assembly SDT probes fail to parse

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

--- Comment #1 from Mark Wielaard <mjw at redhat dot com> 2012-04-01 18:28:28 UTC ---
Some more analysis:
http://sourceware.org/ml/systemtap/2012-q2/msg00001.html

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
jistone at redhat dot com | 1 Apr 2012 21:33
Favicon

[Bug translator/13934] hand-written assembly SDT probes fail to parse

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

Josh Stone <jistone at redhat dot com> changed:

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

--- Comment #2 from Josh Stone <jistone at redhat dot com> 2012-04-01 19:33:49 UTC ---
(In reply to comment #1)
> Some more analysis:
> http://sourceware.org/ml/systemtap/2012-q2/msg00001.html

> For compiler-generated code, each argument will be of the form N <at> OP.
> For hand-written assembly, or for inline assembly in C or C++, the initial
> N <at>  may be missing. If N is present, it describes the size of the argument.
> [...] If N is omitted, the argument size is the natural size of the operand;
> usually this is the size of the register or the word size of the machine.
> In this case, the signedness is ambiguous.

Ugh, I didn't realize SDTv3 exempted assembly from N <at> OP, but indeed that's how
it plays out -- _SDT_ARGFMT is only defined in the !__ASSEMBLY__ case.  That
certainly complicates things... :(

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
(Continue reading)

Permalink | Reply | 0 comments |
headers
fche at redhat dot com | 2 Apr 2012 05:30
Favicon

[Bug translator/13934] hand-written assembly SDT probes fail to parse

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

Frank Ch. Eigler <fche at redhat dot com> changed:

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

--- Comment #3 from Frank Ch. Eigler <fche at redhat dot com> 2012-04-02 03:30:28 UTC ---
One possible solution is to detect the absence of  <at> 's in the sdt-v3 operand
string, and infer that this was an assembler invocation.  Then back down to ' '
based tokenization (and make the spaced-out arm operand unusable).

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
fche at redhat dot com | 2 Apr 2012 21:26
Favicon

[Bug translator/13475] SDT_V3 arm can't parse operand '-4 <at> r3'

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fche at redhat dot com
         Resolution|                            |FIXED

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> 2012-04-02 19:26:53 UTC ---
commit 272c903

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
fche at redhat dot com | 2 Apr 2012 21:27
Favicon

[Bug translator/13474] SDT_V3 arm can't parse operand '4 <at> [fp, #-16]'

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

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fche at redhat dot com
         Resolution|                            |FIXED

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> 2012-04-02 19:27:21 UTC ---
commit 272c903

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
David Smith | 2 Apr 2012 21:30
Picon
Favicon

Re: Improve build-id checking when the task we're interested in isn't 'current'. git commit causing problems on ARM and IA64

On 03/30/2012 04:15 PM, William Cohen wrote:

> When running tests I found the following patch causing problems on ARM and IA64 machines
> 
> http://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=c0456b6fda16307070e0896d3cca86f523214a5e;hp=ca73974d84f94065dbabce2a2044d17a83bade57
> 
> On ARM with a really simple example end up with:
> 
> $ ../install/bin/stap  -k ../systemtap/testsuite/systemtap.base/add.stp 
> WARNING: "copy_to_user_page" [/tmp/stapgL32Wo/stap_7644.ko] undefined!
> Error inserting module '/tmp/stapgL32Wo/stap_7644.ko': Unknown symbol in module
> WARNING: /media/greatplains/wcohen/systemtap_write/install/bin/staprun exited with status: 1
> Pass 5: run failed.  Try again with another '--vp 00001' option.
> Keeping temporary directory "/tmp/stapgL32Wo"

>

> 
> On IA64 same example ends up with:
> 
> $ ../install/bin/stap  -k ../systemtap/testsuite/systemtap.base/add.stp 
> WARNING: "flush_icache_range" [/tmp/staprfDqn5/stap_29610.ko] undefined!
> Error inserting module '/tmp/staprfDqn5/stap_29610.ko': Unknown symbol in module
> WARNING: /home/wcohen/systemtap_write/install/bin/staprun exited with status: 1
> Pass 5: run failed.  Try again with another '--vp 00001' option.
> Keeping temporary directory "/tmp/staprfDqn5"
> 
> 
> It looks like the reordering of the includes is causing a problem on these machines.
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
William Cohen | 2 Apr 2012 22:16
Picon
Favicon

Re: Improve build-id checking when the task we're interested in isn't 'current'. git commit causing problems on ARM and IA64

On 04/02/2012 03:30 PM, David Smith wrote:
> ../install/bin/stap  -k ../systemtap/testsuite/systemtap.base/add.stp 

Hi David,

Thanks for taking a look at this problem.

The git checkin fixes the problem for ia64.

The arm machine is using a kernel from the linus torvald's git repo. This particular kernel doesn't have
utrace support in it, so it doesn't have CONFIG_UTRACE set.  Thus, things still fail in the same way on the
ARM machine.

Does this code work with stock x86_64 kernel?  I am wondering why this problem wasn't seen on the x86 machine.
Does the x86 not need to do the explicit flushes unlike the ia64 and ARM? 

-Will
Permalink | Reply | 5 comments |
headers
David Smith | 3 Apr 2012 00:10
Picon
Favicon

Re: Improve build-id checking when the task we're interested in isn't 'current'. git commit causing problems on ARM and IA64

On 04/02/2012 03:16 PM, William Cohen wrote:

> On 04/02/2012 03:30 PM, David Smith wrote:
>> ../install/bin/stap  -k ../systemtap/testsuite/systemtap.base/add.stp 
> 
> Hi David,
> 
> Thanks for taking a look at this problem.
> 
> The git checkin fixes the problem for ia64.
> 
> The arm machine is using a kernel from the linus torvald's git repo. This particular kernel doesn't

> have utrace support in it, so it doesn't have CONFIG_UTRACE set.
> Thus, things still fail in the same way on the ARM machine.

> 
> Does this code work with stock x86_64 kernel?  I am wondering why this problem wasn't seen on the x86

> machine. Does the x86 not need to do the explicit flushes unlike the
> ia64 and ARM?

Right.  From what I've been looking at on the stock x86_64 kernel,
copy_to_user_page() boils down to a memcpy() call.

Since x86_64 doesn't have an arch-specific cacheflush.h file, it
inherits the following from asm-generic/cacheflush.h:

====
....
(Continue reading)

Permalink | Reply | 4 comments |

Gmane