[PATCH] doc/oops-tracing: add Code: decode info

[PATCH] doc/oops-tracing: add Code: decode info

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

Add info that the Code: bytes line contains <xy> or (wxyz) in some
architecture oops reports and what that means.

Add URL for a script by Andi Kleen that reads the Code: line from an Oops
report file and generates assembly code from the hex bytes.
(This script does not handle Code: lines that contain <xy> or (wxyz)
markings.)

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 Documentation/oops-tracing.txt |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

--- linux-2.6.22-rc5.orig/Documentation/oops-tracing.txt
+++ linux-2.6.22-rc5/Documentation/oops-tracing.txt
@@ -86,6 +86,21 @@ stuff are the values reported by the Oop
 and do a replace of spaces to "\x" - that's what I do, as I'm too lazy 
 to write a program to automate this all).
 
+Alternatively, you can use the shell script from
+<ftp://ftp.firstfloor.org/pub/ak/shell/decodecode>.  Usage is:
+decodecode <oops.txt
+
+The hex bytes that follow "Code:" may (in some architectures) have a series
+of bytes that precede the current instruction pointer as well as bytes at and
+following the current instruction pointer.  In some cases, one instruction
+byte or word is surrounded by <> or (), as in "<86>" or "(f00d)".  These
+<> or () markings indicate the current instruction pointer.  Example from
+i386, split into multiple lines for readability:
+
+Code: f9 0f 8d f9 00 00 00 8d 42 0c e8 dd 26 11 c7 a1 60 ea 2b f9 8b 50 08 a1
+64 ea 2b f9 8d 34 82 8b 1e 85 db 74 6d 8b 15 60 ea 2b f9 <8b> 43 04 39 42 54
+7e 04 40 89 42 54 8b 43 04 3b 05 00 f6 52 c0
+
 Finally, if you want to see where the code comes from, you can do
 
 	cd /usr/src/linux

Re: [PATCH] doc/oops-tracing: add Code: decode info

[Andi Kleen]

On Friday 22 June 2007 07:51:08 Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> Add info that the Code: bytes line contains <xy> or (wxyz) in some
> architecture oops reports and what that means.
> 
> Add URL for a script by Andi Kleen that reads the Code: line from an Oops
> report file and generates assembly code from the hex bytes.
> (This script does not handle Code: lines that contain <xy> or (wxyz)
> markings.)

Should probably fix that and put it into scripts/ then

-Andi

[PATCH v2] doc/oops-tracing: add Code: decode info

[Randy Dunlap]

On Fri, 22 Jun 2007 16:26:39 +0200 Andi Kleen wrote:

> On Friday 22 June 2007 07:51:08 Randy Dunlap wrote:
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> > 
> > Add info that the Code: bytes line contains <xy> or (wxyz) in some
> > architecture oops reports and what that means.
> > 
> > Add URL for a script by Andi Kleen that reads the Code: line from an Oops
> > report file and generates assembly code from the hex bytes.
> > (This script does not handle Code: lines that contain <xy> or (wxyz)
> > markings.)
> 
> Should probably fix that and put it into scripts/ then



From: Randy Dunlap <randy.dunlap@oracle.com>

Add info that the Code: bytes line contains <xy> or (wxyz) in some
architecture oops reports and what that means.

Add a script by Andi Kleen that reads the Code: line from an Oops
report file and generates assembly code from the hex bytes.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 Documentation/oops-tracing.txt |   14 ++++++++++++++
 scripts/decodecode             |   20 ++++++++++++++++++++
 2 files changed, 34 insertions(+)

--- linux-2.6.22-rc5.orig/Documentation/oops-tracing.txt
+++ linux-2.6.22-rc5/Documentation/oops-tracing.txt
@@ -86,6 +86,20 @@ stuff are the values reported by the Oop
 and do a replace of spaces to "\x" - that's what I do, as I'm too lazy 
 to write a program to automate this all).
 
+Alternatively, you can use the shell script in scripts/decodecode.
+Its usage is:  decodecode < oops.txt
+
+The hex bytes that follow "Code:" may (in some architectures) have a series
+of bytes that precede the current instruction pointer as well as bytes at and
+following the current instruction pointer.  In some cases, one instruction
+byte or word is surrounded by <> or (), as in "<86>" or "(f00d)".  These
+<> or () markings indicate the current instruction pointer.  Example from
+i386, split into multiple lines for readability:
+
+Code: f9 0f 8d f9 00 00 00 8d 42 0c e8 dd 26 11 c7 a1 60 ea 2b f9 8b 50 08 a1
+64 ea 2b f9 8d 34 82 8b 1e 85 db 74 6d 8b 15 60 ea 2b f9 <8b> 43 04 39 42 54
+7e 04 40 89 42 54 8b 43 04 3b 05 00 f6 52 c0
+
 Finally, if you want to see where the code comes from, you can do
 
 	cd /usr/src/linux
--- /dev/null
+++ linux-2.6.22-rc5/scripts/decodecode
@@ -0,0 +1,20 @@
+#!/bin/sh
+# Disassemble the Code: line in Linux oopses
+# usage: decodecode < oops.file
+
+T=`mktemp`
+
+while read i ; do
+
+case "$i" in
+*Code:*)
+	echo $i
+	echo -n "	.byte 0x" > $T.s
+	echo $i | sed -e 's/.*Code: //;s/ [<(]/ /;s/[>)] / /;s/ /,0x/g' >> $T.s
+	as -o $T.o $T.s
+	objdump -S $T.o
+	rm $T.o $T.s
+	;;
+esac
+
+done

Re: [PATCH v2] doc/oops-tracing: add Code: decode info

[Andi Kleen]

On Friday 22 June 2007 18:44, Randy Dunlap wrote:
> On Fri, 22 Jun 2007 16:26:39 +0200 Andi Kleen wrote:
> > On Friday 22 June 2007 07:51:08 Randy Dunlap wrote:
> > > From: Randy Dunlap <randy.dunlap@oracle.com>
> > >
> > > Add info that the Code: bytes line contains <xy> or (wxyz) in some
> > > architecture oops reports and what that means.
> > >
> > > Add URL for a script by Andi Kleen that reads the Code: line from an
> > > Oops report file and generates assembly code from the hex bytes.
> > > (This script does not handle Code: lines that contain <xy> or (wxyz)
> > > markings.)
> >
> > Should probably fix that and put it into scripts/ then
>
> From: Randy Dunlap <randy.dunlap@oracle.com>

Thanks.

>
> +*Code:*)
> +	echo $i
> +	echo -n "	.byte 0x" > $T.s
> +	echo $i | sed -e 's/.*Code: //;s/ [<(]/ /;s/[>)] / /;s/ /,0x/g' >> $T.s
> +	as -o $T.o $T.s
> +	objdump -S $T.o

This still has a couple of problems:

- The <> information is lost. It would be better to split and run 
objdump three times and insert a marker
- It won't handle multiline Code:s which i386 likes to generate now I think

-Andi

Re: [PATCH v2] doc/oops-tracing: add Code: decode info

[Randy Dunlap]

On Fri, 22 Jun 2007 19:23:02 +0200 Andi Kleen wrote:

> On Friday 22 June 2007 18:44, Randy Dunlap wrote:
> > On Fri, 22 Jun 2007 16:26:39 +0200 Andi Kleen wrote:
> > > On Friday 22 June 2007 07:51:08 Randy Dunlap wrote:
> > > > From: Randy Dunlap <randy.dunlap@oracle.com>
> > > >
> > > > Add info that the Code: bytes line contains <xy> or (wxyz) in some
> > > > architecture oops reports and what that means.
> > > >
> > > > Add URL for a script by Andi Kleen that reads the Code: line from an
> > > > Oops report file and generates assembly code from the hex bytes.
> > > > (This script does not handle Code: lines that contain <xy> or (wxyz)
> > > > markings.)
> > >
> > > Should probably fix that and put it into scripts/ then
> >
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> Thanks.
> 
> >
> > +*Code:*)
> > +	echo $i
> > +	echo -n "	.byte 0x" > $T.s
> > +	echo $i | sed -e 's/.*Code: //;s/ [<(]/ /;s/[>)] / /;s/ /,0x/g' >> $T.s
> > +	as -o $T.o $T.s
> > +	objdump -S $T.o
> 
> This still has a couple of problems:
> 
> - The <> information is lost. It would be better to split and run 
> objdump three times and insert a marker

Why 3 times?  Why not just (1) everything before marker and
(2) everything at and after marker?

> - It won't handle multiline Code:s which i386 likes to generate now I think

I don't see the code in arch/i386/kernel/traps.c generating multiline
Code:s, just very long single lines.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH v2] doc/oops-tracing: add Code: decode info

[Andi Kleen]

> Why 3 times?  Why not just (1) everything before marker and
> (2) everything at and after marker?

2 times would probably work too, i was just thinking of a marker around it;
but you're right just before would be also ok.

> > - It won't handle multiline Code:s which i386 likes to generate now I
> > think
>
> I don't see the code in arch/i386/kernel/traps.c generating multiline
> Code:s, just very long single lines.

Yes I must have mislooked.

-Andi

[PATCH v3] doc/oops-tracing: add Code: decode info

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

Add info that the Code: bytes line contains <xy> or (wxyz) in some
architecture oops reports and what that means.

Add a script by Andi Kleen that reads the Code: line from an Oops
report file and generates assembly code from the hex bytes.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 Documentation/oops-tracing.txt |   14 ++++++++++++
 scripts/decodecode             |   47 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 61 insertions(+)

--- linux-2.6.22-rc5.orig/Documentation/oops-tracing.txt
+++ linux-2.6.22-rc5/Documentation/oops-tracing.txt
@@ -86,6 +86,20 @@ stuff are the values reported by the Oop
 and do a replace of spaces to "\x" - that's what I do, as I'm too lazy 
 to write a program to automate this all).
 
+Alternatively, you can use the shell script in scripts/decodecode.
+Its usage is:  decodecode < oops.txt
+
+The hex bytes that follow "Code:" may (in some architectures) have a series
+of bytes that precede the current instruction pointer as well as bytes at and
+following the current instruction pointer.  In some cases, one instruction
+byte or word is surrounded by <> or (), as in "<86>" or "(f00d)".  These
+<> or () markings indicate the current instruction pointer.  Example from
+i386, split into multiple lines for readability:
+
+Code: f9 0f 8d f9 00 00 00 8d 42 0c e8 dd 26 11 c7 a1 60 ea 2b f9 8b 50 08 a1
+64 ea 2b f9 8d 34 82 8b 1e 85 db 74 6d 8b 15 60 ea 2b f9 <8b> 43 04 39 42 54
+7e 04 40 89 42 54 8b 43 04 3b 05 00 f6 52 c0
+
 Finally, if you want to see where the code comes from, you can do
 
 	cd /usr/src/linux
--- /dev/null
+++ linux-2.6.22-rc5/scripts/decodecode
@@ -0,0 +1,47 @@
+#!/bin/sh
+# Disassemble the Code: line in Linux oopses
+# usage: decodecode < oops.file
+
+T=`mktemp`
+code=
+
+while read i ; do
+
+case "$i" in
+*Code:*)
+	code=$i
+	;;
+esac
+
+done
+
+if [ -z "$code" ]; then
+	exit
+fi
+
+echo $code
+code=`echo $code | sed -e 's/.*Code: //'`
+
+marker=`expr index "$code" "\<"`
+if [ $marker -eq 0 ]; then
+	marker=`expr index "$code" "\("`
+fi
+
+if [ $marker -ne 0 ]; then
+	beforemark=${code:0:$((marker - 1))}
+	echo -n "	.byte 0x" > $T.s
+	echo $beforemark | sed -e 's/ /,0x/g' >> $T.s
+	as -o $T.o $T.s
+	objdump -S $T.o
+	rm $T.o $T.s
+
+# and fix code at-and-after marker
+	code=${code:$marker}
+fi
+
+code=`echo $code | sed -e 's/ [<(]/ /;s/[>)] / /;s/ /,0x/g'`
+echo -n "	.byte 0x" > $T.s
+echo $code >> $T.s
+as -o $T.o $T.s
+objdump -S $T.o
+rm $T.o $T.s

NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Oleg Verych]

* From: Randy Dunlap
* Newsgroups: linux.kernel
* Date: Fri, 22 Jun 2007 13:28:10 -0700
* Organization: Oracle Linux Eng.

[]
> --- /dev/null
> +++ linux-2.6.22-rc5/scripts/decodecode
> @@ -0,0 +1,47 @@
> +#!/bin/sh
> +# Disassemble the Code: line in Linux oopses
> +# usage: decodecode < oops.file

|-*- sh = dash -*-
flower:-$ <kernelOops.txt sh decodecode
Jun 18 22:05:11 localhost kernel: Code: 00 00 00 eb 1b 6b 4e 38 05 89 ca 03 53 \
1c 4a 89 d0 31 d2 f7 f1 89 da 89 c1 89 f0 e8 83 ed ff ff e8 26 af 12 00 8b 76 6\
4 83 ee 64 <8b> 46 64 0f 18 00 90 81 fe 14 5c 37 c0 0f 85 70 ff ff ff b8 84
decodecode: 31: Syntax error: Bad substitution
flower:-$
|-*-

Or you are writing for "#!/bin/bash", or i can help optimize and make
this script "sh" compatible.

NAK.
--
  frenzy
-o--=O`C
 #oo'L O
<___=E M

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Andi Kleen]

Here's a nickel. Get yourself a real shell.

-Andi

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Arkadiusz Miskiewicz]

On Saturday 23 of June 2007, Andi Kleen wrote:
> Here's a nickel. Get yourself a real shell.

POSIX compilant shell isn't real shell?

> -Andi

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Andi Kleen]

On Saturday 23 June 2007 13:09, Arkadiusz Miskiewicz wrote:
> On Saturday 23 of June 2007, Andi Kleen wrote:
> > Here's a nickel. Get yourself a real shell.
>
> POSIX compilant shell isn't real shell?

In this case it's not good enough. We're not writing POSIX portable software 
here, but Linux software where /bin/sh is /bin/bash. Similar to the Linux 
kernel which is not written in portable ISO C.

-Andi

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Willy Tarreau]

On Sat, Jun 23, 2007 at 03:17:27PM +0200, Andi Kleen wrote:
> On Saturday 23 June 2007 13:09, Arkadiusz Miskiewicz wrote:
> > On Saturday 23 of June 2007, Andi Kleen wrote:
> > > Here's a nickel. Get yourself a real shell.
> >
> > POSIX compilant shell isn't real shell?
> 
> In this case it's not good enough. We're not writing POSIX portable software 
> here, but Linux software where /bin/sh is /bin/bash. Similar to the Linux 
> kernel which is not written in portable ISO C.

Well, it can also be zsh or pdksh, but I suspect that the code is valid on
them too.

Willy

[OT]Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Oleg Verych]

On Sat, Jun 23, 2007 at 03:26:26PM +0200, Willy Tarreau wrote:
> On Sat, Jun 23, 2007 at 03:17:27PM +0200, Andi Kleen wrote:
> > On Saturday 23 June 2007 13:09, Arkadiusz Miskiewicz wrote:
> > > On Saturday 23 of June 2007, Andi Kleen wrote:
> > > > Here's a nickel. Get yourself a real shell.
> > >
> > > POSIX compilant shell isn't real shell?
> > 
> > In this case it's not good enough. We're not writing POSIX portable software 
> > here, but Linux software where /bin/sh is /bin/bash. Similar to the Linux 
> > kernel which is not written in portable ISO C.

I disagree.

> Well, it can also be zsh or pdksh, but I suspect that the code is valid on
> them too.

Not for the latter:
|-*- pdksh -*-
flower:-$ <kernelOops.txt>/dev/null pdksh decodecode
decodecode[40]: : bad substitution
flower:-$
|-*-

I don't want to go further with this OT, just last thing.

It's GNU BaSH *BUG* (addition to being big and slow), if it can't switch
off it's expressly undocumented extentions while run as `/bin/sh'.
____

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Björn Steinbrink]

On 2007.06.23 15:17:27 +0200, Andi Kleen wrote:
> On Saturday 23 June 2007 13:09, Arkadiusz Miskiewicz wrote:
> > On Saturday 23 of June 2007, Andi Kleen wrote:
> > > Here's a nickel. Get yourself a real shell.
> >
> > POSIX compilant shell isn't real shell?
> 
> In this case it's not good enough. We're not writing POSIX portable software 
> here, but Linux software where /bin/sh is /bin/bash. Similar to the Linux 
> kernel which is not written in portable ISO C.

At least LSB 3.1 doesn't require /bin/sh to be /bin/bash. And if you
want bash, what's the problem with just writing #!/bin/bash instead of
#!/bin/sh?


Björn

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Arkadiusz Miskiewicz]

On Saturday 23 of June 2007, Andi Kleen wrote:
> On Saturday 23 June 2007 13:09, Arkadiusz Miskiewicz wrote:
> > On Saturday 23 of June 2007, Andi Kleen wrote:
> > > Here's a nickel. Get yourself a real shell.
> >
> > POSIX compilant shell isn't real shell?
>
> In this case it's not good enough. We're not writing POSIX portable
> software here, but Linux software where /bin/sh is /bin/bash.

Here on my Linux software /bin/sh is pdksh and bash installation is 
*optional*.

Is it so hard to tell truth in first line of shell script, tha it NEEDS 
exactly bash (#!/bin/bash) ?

> -Andi

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Alan Cox]

On Sat, 23 Jun 2007 15:17:27 +0200
Andi Kleen <ak@suse.de> wrote:

> On Saturday 23 June 2007 13:09, Arkadiusz Miskiewicz wrote:
> > On Saturday 23 of June 2007, Andi Kleen wrote:
> > > Here's a nickel. Get yourself a real shell.
> >
> > POSIX compilant shell isn't real shell?
> 
> In this case it's not good enough. We're not writing POSIX portable software 
> here, but Linux software where /bin/sh is /bin/bash. Similar to the Linux 
> kernel which is not written in portable ISO C.

Having the scripts work with other shells is very helpful for porting,
cross building and the like. Also on Linux /bin/sh is not
neccessarily /bin/bash.

Alan

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Andi Kleen]

On Saturday 23 June 2007 16:32:39 Alan Cox wrote:
 
> Having the scripts work with other shells is very helpful for porting,
> cross building and the like.

Well then for the majority of cross compile users you should consequently write 
them in Windows batch language.

> Also on Linux /bin/sh is not 
> neccessarily /bin/bash.

If it's not I think these few distributions give Linux a bad name 
because they introduce quite unnecessary incompatibilities.
Hopefully they are not widely used.

-Andi

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Alan Cox]

On Sat, 23 Jun 2007 16:34:42 +0200
Andi Kleen <ak@suse.de> wrote:

> On Saturday 23 June 2007 16:32:39 Alan Cox wrote:
>  
> > Having the scripts work with other shells is very helpful for porting,
> > cross building and the like.
> 
> Well then for the majority of cross compile users you should consequently write 
> them in Windows batch language.

That isn't portable or standardised. And there are posix shells for
Windows if you really want to cross build on Windows (and some folks do
for embedded because of debug/ice enviroments - pity them)

> > Also on Linux /bin/sh is not 
> > neccessarily /bin/bash.
> 
> If it's not I think these few distributions give Linux a bad name 
> because they introduce quite unnecessary incompatibilities.
> Hopefully they are not widely used.

On the contrary, it is you who is causing incompatibilities by objecting
to the use of standards compliant behaviour. This is the world according
to the standards not the world according to Andi Kleen. (Which one would
run better is a different debate to which one we live in ;))

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Segher Boessenkool]

> Having the scripts work with other shells is very helpful for porting,
> cross building and the like.

I think it is fair game to require bash to build the
kernel -- after all, GCC and GNU make are required
already, and bash has many helpful features that not
every POSIX shell has.

> Also on Linux /bin/sh is not neccessarily /bin/bash.

Yes, it would be ridiculous to require /bin/sh to be
bash.  Especially since bash is installed as /bin/bash
always :-)


Segher

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Sean]

On Sat, 23 Jun 2007 15:17:27 +0200
Andi Kleen <ak@suse.de> wrote:

> In this case it's not good enough. We're not writing POSIX portable software 
> here, but Linux software where /bin/sh is /bin/bash. Similar to the Linux 
> kernel which is not written in portable ISO C.

There's no rule that says /bin/sh is always /bin/bash.  What Novell
distributions do does not translate to all of "Linux".  If you are writing
scripts that rely on bash then "#!/bin/bash" is the appropriate way to
document that and give it the best chance of working portably.

Sean

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Oleg Verych]

On Sat, Jun 23, 2007 at 03:17:27PM +0200, Andi Kleen wrote:
> On Saturday 23 June 2007 13:09, Arkadiusz Miskiewicz wrote:
> > On Saturday 23 of June 2007, Andi Kleen wrote:
> > > Here's a nickel. Get yourself a real shell.
> >
> > POSIX compilant shell isn't real shell?
> 
> In this case it's not good enough. We're not writing POSIX portable software 
> here, but Linux software where /bin/sh is /bin/bash. Similar to the Linux 
> kernel which is not written in portable ISO C.

Technical reply about my disagreement.

It's a problem more like "it's broken, but somebody use this in the
source tree". Good example is if "someone uses page_mapping on a slab
page" and have oops with SLUB:

Message-ID: <Pine.LNX.4.64.0706221531520.19704@schroedinger.engr.sgi.com>
Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/546758>

Thus, if one doesn't know what `#!/bin/sh' really is, don't
"syntax error" with possible another sh[ell]. In the Linux build system
$(CONFIG_SHELL) currently is bash, but that's only in the kbuild *now*.

Hope that clarifies.
____

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Randy Dunlap]

On Sat, 23 Jun 2007 10:34:59 +0200 Oleg Verych wrote:

> * From: Randy Dunlap
> * Newsgroups: linux.kernel
> * Date: Fri, 22 Jun 2007 13:28:10 -0700
> * Organization: Oracle Linux Eng.
> 
> []
> > --- /dev/null
> > +++ linux-2.6.22-rc5/scripts/decodecode
> > @@ -0,0 +1,47 @@
> > +#!/bin/sh
> > +# Disassemble the Code: line in Linux oopses
> > +# usage: decodecode < oops.file
> 
> |-*- sh = dash -*-
> flower:-$ <kernelOops.txt sh decodecode
> Jun 18 22:05:11 localhost kernel: Code: 00 00 00 eb 1b 6b 4e 38 05 89 ca 03 53 \
> 1c 4a 89 d0 31 d2 f7 f1 89 da 89 c1 89 f0 e8 83 ed ff ff e8 26 af 12 00 8b 76 6\
> 4 83 ee 64 <8b> 46 64 0f 18 00 90 81 fe 14 5c 37 c0 0f 85 70 ff ff ff b8 84
> decodecode: 31: Syntax error: Bad substitution
> flower:-$
> |-*-
> 
> Or you are writing for "#!/bin/bash", or i can help optimize and make
> this script "sh" compatible.
> 
> NAK.

Sorry I slept thru another wonderful festival on LKML.

You don't have the authority to NAK the patch.

OTOH, you also didn't supply a patch.  If you do this, I'll be
glad to consider it.  If I can read it, that is.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Andrew Morton]

On Sat, 23 Jun 2007 10:43:03 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:

> > NAK.
> 
> Sorry I slept thru another wonderful festival on LKML.

That's probably the best strategy.

> You don't have the authority to NAK the patch.

Yeah.  nak to naks.

> OTOH, you also didn't supply a patch.  If you do this, I'll be
> glad to consider it.  If I can read it, that is.

Yes, I plan on merging that patch as-is.  If it was a compulsory part of
kbuild then that would be a problem but as some optional tool I don't think
that a bashism matters much.  Someone can fix it sometime should they feel
so motivated.

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Adrian Bunk]

On Sat, Jun 23, 2007 at 10:56:45AM -0700, Andrew Morton wrote:
> On Sat, 23 Jun 2007 10:43:03 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
> > > NAK.
> > 
> > Sorry I slept thru another wonderful festival on LKML.
> 
> That's probably the best strategy.
> 
> > You don't have the authority to NAK the patch.
> 
> Yeah.  nak to naks.
> 
> > OTOH, you also didn't supply a patch.  If you do this, I'll be
> > glad to consider it.  If I can read it, that is.
> 
> Yes, I plan on merging that patch as-is.  If it was a compulsory part of
> kbuild then that would be a problem but as some optional tool I don't think
> that a bashism matters much.  Someone can fix it sometime should they feel
> so motivated.

Oleg didn't express it very polite, but he has a valid point that bash 
scripts should start with "#!/bin/bash" since /bin/sh might be some 
shell other than bash.

Randy, am I right to assume that such a change to your patch would be OK?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Randy Dunlap]

Adrian Bunk wrote:
> On Sat, Jun 23, 2007 at 10:56:45AM -0700, Andrew Morton wrote:
>> On Sat, 23 Jun 2007 10:43:03 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>>
>>>> NAK.
>>> Sorry I slept thru another wonderful festival on LKML.
>> That's probably the best strategy.
>>
>>> You don't have the authority to NAK the patch.
>> Yeah.  nak to naks.
>>
>>> OTOH, you also didn't supply a patch.  If you do this, I'll be
>>> glad to consider it.  If I can read it, that is.
>> Yes, I plan on merging that patch as-is.  If it was a compulsory part of
>> kbuild then that would be a problem but as some optional tool I don't think
>> that a bashism matters much.  Someone can fix it sometime should they feel
>> so motivated.
> 
> Oleg didn't express it very polite, but he has a valid point that bash 
> scripts should start with "#!/bin/bash" since /bin/sh might be some 
> shell other than bash.
> 
> Randy, am I right to assume that such a change to your patch would be OK?

Sure.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Matthieu CASTET]

Hi,

On Sat, 23 Jun 2007 10:43:03 -0700, Randy Dunlap wrote:

> OTOH, you also didn't supply a patch.  If you do this, I'll be glad to
> consider it.  If I can read it, that is.

"s|/bin/sh|/bin/bash" is so hard to do ?

Matthieu

PS : this remind me http://www.landley.net/code/firmware/ . Is it so 
difficult to understand that sh is not bash. It is like assuming that 
everybody as a "qwerty" keyboard.

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[DervishD]

    Hi Matthieu :)

 * Matthieu CASTET <castet.matthieu@free.fr> dixit:
> On Sat, 23 Jun 2007 10:43:03 -0700, Randy Dunlap wrote:
> 
> > OTOH, you also didn't supply a patch.  If you do this, I'll be glad to
> > consider it.  If I can read it, that is.
> 
> "s|/bin/sh|/bin/bash" is so hard to do ?

    Given that it happens too with "ldd", it really *is* that hard. I
don't know why still people think that /bin/sh is always /bin/bash. If
they want/need bash, that's ok to me, I will have it installed for such
tasks, but they should call it "#!/bin/bash".

    It seems easier to say "get a real shell" (as if Bash was the only
real shell) than fixing that bug...

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

On Tue, 2007-06-26 12:16:39 +0200, DervishD <lkml@dervishd.net> wrote:
>  * Matthieu CASTET <castet.matthieu@free.fr> dixit:
> > On Sat, 23 Jun 2007 10:43:03 -0700, Randy Dunlap wrote:
> > 
> > > OTOH, you also didn't supply a patch.  If you do this, I'll be glad to
> > > consider it.  If I can read it, that is.
> > 
> > "s|/bin/sh|/bin/bash" is so hard to do ?
> 
>     Given that it happens too with "ldd", it really *is* that hard. I
> don't know why still people think that /bin/sh is always /bin/bash. If
> they want/need bash, that's ok to me, I will have it installed for such
> tasks, but they should call it "#!/bin/bash".

...or "#!/usr/bin/env bash" for what it's worth...  The same for plain
`sh'.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
 Signature of:                      http://perl.plover.com/Questions.html
 the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[DervishD]

    Hi Jan :)

 * Jan-Benedict Glaw <jbglaw@lug-owl.de> dixit:
> On Tue, 2007-06-26 12:16:39 +0200, DervishD <lkml@dervishd.net> wrote:
> >     Given that it happens too with "ldd", it really *is* that hard. I
> > don't know why still people think that /bin/sh is always /bin/bash. If
> > they want/need bash, that's ok to me, I will have it installed for such
> > tasks, but they should call it "#!/bin/bash".
> 
> ...or "#!/usr/bin/env bash" for what it's worth...  The same for plain
> `sh'.

    The "env" solution is a bit of a problem, too. Not always "env" is
installed in /usr/bin, but in /bin, so it is available even if /usr is
not still mounted. But /bin/sh is pretty standard (as it should be
/bin/bash, anyway), and it's only two chars shorter than the correct
"/bin/bash". No idea why it is not fixed.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Randy Dunlap]

On Tue, 26 Jun 2007 17:33:59 +0200 DervishD wrote:

>     Hi Jan :)
> 
>  * Jan-Benedict Glaw <jbglaw@lug-owl.de> dixit:
> > On Tue, 2007-06-26 12:16:39 +0200, DervishD <lkml@dervishd.net> wrote:
> > >     Given that it happens too with "ldd", it really *is* that hard. I
> > > don't know why still people think that /bin/sh is always /bin/bash. If
> > > they want/need bash, that's ok to me, I will have it installed for such
> > > tasks, but they should call it "#!/bin/bash".
> > 
> > ...or "#!/usr/bin/env bash" for what it's worth...  The same for plain
> > `sh'.
> 
>     The "env" solution is a bit of a problem, too. Not always "env" is
> installed in /usr/bin, but in /bin, so it is available even if /usr is
> not still mounted. But /bin/sh is pretty standard (as it should be
> /bin/bash, anyway), and it's only two chars shorter than the correct
> "/bin/bash". No idea why it is not fixed.

because nobody sent a patch yet?

but I'll get around tuit.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[DervishD]

    Hi Randy :)

 * Randy Dunlap <randy.dunlap@oracle.com> dixit:
> On Tue, 26 Jun 2007 17:33:59 +0200 DervishD wrote:
> >  * Jan-Benedict Glaw <jbglaw@lug-owl.de> dixit:
> > > On Tue, 2007-06-26 12:16:39 +0200, DervishD <lkml@dervishd.net> wrote:
> > > >     Given that it happens too with "ldd", it really *is* that hard. I
> > > > don't know why still people think that /bin/sh is always /bin/bash. If
> > > > they want/need bash, that's ok to me, I will have it installed for such
> > > > tasks, but they should call it "#!/bin/bash".
> > > 
> > > ...or "#!/usr/bin/env bash" for what it's worth...  The same for plain
> > > `sh'.
> > 
> >     The "env" solution is a bit of a problem, too. Not always "env" is
> > installed in /usr/bin, but in /bin, so it is available even if /usr is
> > not still mounted. But /bin/sh is pretty standard (as it should be
> > /bin/bash, anyway), and it's only two chars shorter than the correct
> > "/bin/bash". No idea why it is not fixed.
> 
> because nobody sent a patch yet?
> 
> but I'll get around tuit.

    Sorry, I wasn't speaking about your patch, I was talking about the
"ldd" issue (and others like that). When I was preparing the patch for
"ldd" I saw in a mailing list archive the answer given to somebody that
tried exactly the same and I lost all interest in patching "ldd".

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Arne Georg Gleditsch]

Randy Dunlap <randy.dunlap@oracle.com> writes:
> OTOH, you also didn't supply a patch.  If you do this, I'll be
> glad to consider it.  If I can read it, that is.

I like bash as much as the next guy, but (to my surprise) /bin/sh on
my current workstation is actually dash.  How about just replacing the
substring-interpolations with:

if [ $marker -ne 0 ]; then
	beforemark=`echo "$code" | cut -c-$((marker - 1))`
[..]
# and fix code at-and-after marker
	code=`echo "$code" | cut -c$marker-`
fi

and be done with it?

-- 
								Arne.

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[DervishD]

    Hi Arne :)

 * Arne Georg Gleditsch <argggh@dolphinics.no> dixit:
> Randy Dunlap <randy.dunlap@oracle.com> writes:
> > OTOH, you also didn't supply a patch.  If you do this, I'll be
> > glad to consider it.  If I can read it, that is.
> 
> I like bash as much as the next guy, but (to my surprise) /bin/sh on
> my current workstation is actually dash.

    You're probably using Ubuntu, am I right? I have a do-it-yourself
Linux box and my /bin/sh is dash. It is POSIX compliant, small and
lightning fast. I use as a reference shell. I have installed zsh and
bash, too, and sometimes I have to relink /bin/sh to point to /bin/bash
so certain scripts work...

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Randy Dunlap]

On Tue, 26 Jun 2007 12:50:27 +0200 Arne Georg Gleditsch wrote:

> Randy Dunlap <randy.dunlap@oracle.com> writes:
> > OTOH, you also didn't supply a patch.  If you do this, I'll be
> > glad to consider it.  If I can read it, that is.
> 
> I like bash as much as the next guy, but (to my surprise) /bin/sh on
> my current workstation is actually dash.  How about just replacing the
> substring-interpolations with:
> 
> if [ $marker -ne 0 ]; then
> 	beforemark=`echo "$code" | cut -c-$((marker - 1))`
> [..]
> # and fix code at-and-after marker
> 	code=`echo "$code" | cut -c$marker-`
> fi
> 
> and be done with it?


Are these 2 line changes all that is needed?

I sort of expected expressions like $((a + 2)) to need change also...
maybe not for dash, but for sh?

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Julio M. Merino Vidal]

On 26/06/2007, at 19:19, Randy Dunlap wrote:
>
> Are these 2 line changes all that is needed?
>
> I sort of expected expressions like $((a + 2)) to need change also...
> maybe not for dash, but for sh?

The correct expression could be $((${a} + 2)).  Tested under NetBSD's  
sh, which is very POSIX-compliant.

-- 
Julio M. Merino Vidal <jmerino@ac.upc.edu>

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Randy Dunlap]

On Tue, 26 Jun 2007 19:25:00 +0200 Julio M. Merino Vidal wrote:

> On 26/06/2007, at 19:19, Randy Dunlap wrote:
> >
> > Are these 2 line changes all that is needed?
> >
> > I sort of expected expressions like $((a + 2)) to need change also...
> > maybe not for dash, but for sh?
> 
> The correct expression could be $((${a} + 2)).  Tested under NetBSD's  
> sh, which is very POSIX-compliant.

Thanks.  Does anyone see other changes that are needed?


The diff currently looks like:

--- decodecode.~3~	2007-06-22 13:25:39.000000000 -0700
+++ decodecode	2007-06-26 10:40:28.000000000 -0700
@@ -28,7 +28,7 @@
 fi
 
 if [ $marker -ne 0 ]; then
-	beforemark=${code:0:$((marker - 1))}
+	beforemark=`echo "$code" | cut -c-$((${marker} - 1))`
 	echo -n "	.byte 0x" > $T.s
 	echo $beforemark | sed -e 's/ /,0x/g' >> $T.s
 	as -o $T.o $T.s
@@ -36,7 +36,7 @@
 	rm $T.o $T.s
 
 # and fix code at-and-after marker
-	code=${code:$marker}
+	code=`echo "$code" | cut -c$((${marker} + 1))-`
 fi
 
 code=`echo $code | sed -e 's/ [<(]/ /;s/[>)] / /;s/ /,0x/g'`




and the complete script is:

#!/bin/sh
# Disassemble the Code: line in Linux oopses
# usage: decodecode < oops.file

T=`mktemp`
code=

while read i ; do

case "$i" in
*Code:*)
	code=$i
	;;
esac

done

if [ -z "$code" ]; then
	exit
fi

echo $code
code=`echo $code | sed -e 's/.*Code: //'`

marker=`expr index "$code" "\<"`
if [ $marker -eq 0 ]; then
	marker=`expr index "$code" "\("`
fi

if [ $marker -ne 0 ]; then
	beforemark=`echo "$code" | cut -c-$((${marker} - 1))`
	echo -n "	.byte 0x" > $T.s
	echo $beforemark | sed -e 's/ /,0x/g' >> $T.s
	as -o $T.o $T.s
	objdump -S $T.o
	rm $T.o $T.s

# and fix code at-and-after marker
	code=`echo "$code" | cut -c$((${marker} + 1))-`
fi

code=`echo $code | sed -e 's/ [<(]/ /;s/[>)] / /;s/ /,0x/g'`
echo -n "	.byte 0x" > $T.s
echo $code >> $T.s
as -o $T.o $T.s
objdump -S $T.o
rm $T.o $T.s

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Arne Georg Gleditsch]

Randy Dunlap <randy.dunlap@oracle.com> writes:
> On Tue, 26 Jun 2007 19:25:00 +0200 Julio M. Merino Vidal wrote:
>> The correct expression could be $((${a} + 2)).  Tested under NetBSD's  
>> sh, which is very POSIX-compliant.
>
> Thanks.  Does anyone see other changes that are needed?

[..]

> and the complete script is:

Both busybox sh and dash are happy with this.  (Or rather, busybox
would be if its mktemp hadn't been broken.)

-- 
								Arne.