[Bug runtime/10172] New: sdt.h on powerpc Error: junk at end of line: `0'

[Bug runtime/10172] New: sdt.h on powerpc Error: junk at end of line: `0'

[mjw at redhat dot com]

According to https://bugzilla.redhat.com/show_bug.cgi?id=489017#c13 sdt.h
stopped compiling on powerpc (ppc64). Error: junk at end of line: `0'
sounds familiar, that was most likely introduced in:

commit 1ce4311fbb8e3191449f919b784cea355a0cfe00
Author: Stan Cox <scox@redhat.com>
Date:   Thu Apr 23 16:43:44 2009 -0400

    Avoid a uprobe break setting problem by avoiding 'nop 0' on x86.

    * sdt.h (STAP_NOP): New.
    (STAP_PROBE): Use it.

I don't have a powerpc machine around. But I suspect it might be fixed by
something like:

diff --git a/includes/sys/sdt.h b/includes/sys/sdt.h
index 5899549..fd2c55f 100644
--- a/includes/sys/sdt.h
+++ b/includes/sys/sdt.h
@@ -59,7 +59,7 @@
 #define STAP_UNINLINE_LABEL(label) \
   __extension__ static volatile long labelval  __attribute__ ((unused)) =
(long

-#if defined(__x86_64__) || defined(__i386__)
+#if defined(__x86_64__) || defined(__i386__) || defined(__powerpc__)
 #define STAP_NOP "\tnop "
 #else
 #define STAP_NOP "\tnop 0 " 

It might not be __powerpc__ though, it might only be __ppc64__.
Could someone with access to powerpc test this out? An easy test would be to see
whether 'make check RUNTESTFLAGS=sdt.exp' reports any failures.

A similar issue was mentioned in a recent test report thread on the mailinglist:
http://sourceware.org/ml/systemtap/2009-q2/msg00472.html

-- 
           Summary: sdt.h on powerpc Error: junk at end of line: `0'
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: mjw at redhat dot com
                CC: ananth at in dot ibm dot com,scox at redhat dot com


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

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

[Bug runtime/10172] sdt.h on powerpc Error: junk at end of line: `0'

[mahesh at linux dot vnet dot ibm dot com]

------- Additional Comments From mahesh at linux dot vnet dot ibm dot com  2009-05-20 10:33 -------
Tested your patch on ppc64 system and it works. Yes it is __powerpc__ and not
__ppc64__

---------------
Host: Linux llm27lp1.in.ibm.com 2.6.30-rc5 #1 SMP Tue May 12 17:15:22 IST 2009
ppc64 ppc64 ppc64 GNU/Linux
Snapshot: version 0.9.7/0.140 commit release-0.9.7-145-gce95025 + changes
Distro: Red Hat Enterprise Linux Server release 5.2 (Tikanga)

Running /home/mahesh/systemtap/systemtap/testsuite/systemtap.base/sdt.exp ...

		=== systemtap Summary ===

# of expected passes		14
# of untested testcases		14
make[2]: Leaving directory `/home/mahesh/systemtap/systemtap/testsuite'
if test -n ""; then mail  < systemtap.sum; fi
make[1]: Leaving directory
-----------------

-- 


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

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

[Bug runtime/10172] sdt.h on powerpc Error: junk at end of line: `0'

[mjw at redhat dot com]

------- Additional Comments From mjw at redhat dot com  2009-05-20 10:43 -------
Thanks for testing. Pushed as follows:

commit 78c9d72e18da2d5c930fb39460c236ea24fee423
Author: Mark Wielaard <mjw@redhat.com>
Date:   Wed May 20 12:39:57 2009 +0200

    PR10172 sdt.h on powerpc Error: junk at end of line: `0'
    
    * includes/sys/sdt.h (STAP_NOP): __powerpc__ doesn't want an extra 0.
    
    Tested-by: Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com>


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


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

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