From: Randy Dunlap <[email protected]>
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 <[email protected]>
---
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
On Friday 22 June 2007 07:51:08 Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> 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
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 <[email protected]>
> >
> > 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 <[email protected]>
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 <[email protected]>
---
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
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 <[email protected]>
> > >
> > > 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 <[email protected]>
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
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 <[email protected]>
> > > >
> > > > 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 <[email protected]>
>
> 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 ***
From: Randy Dunlap <[email protected]>
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 <[email protected]>
---
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
> 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
* 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
Here's a nickel. Get yourself a real shell.
-Andi
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/
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
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
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'.
____
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
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/
On Sat, 23 Jun 2007 15:17:27 +0200
Andi Kleen <[email protected]> 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
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
On Sat, 23 Jun 2007 15:17:27 +0200
Andi Kleen <[email protected]> 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
On Sat, 23 Jun 2007 16:34:42 +0200
Andi Kleen <[email protected]> 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 ;))
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: <[email protected]>
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.
____
> 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
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 ***
On Sat, 23 Jun 2007 10:43:03 -0700 Randy Dunlap <[email protected]> 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.
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.
On Sat, Jun 23, 2007 at 10:56:45AM -0700, Andrew Morton wrote:
> On Sat, 23 Jun 2007 10:43:03 -0700 Randy Dunlap <[email protected]> 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
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 <[email protected]> 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 ***
Hi Matthieu :)
* Matthieu CASTET <[email protected]> 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!
On Tue, 2007-06-26 12:16:39 +0200, DervishD <[email protected]> wrote:
> * Matthieu CASTET <[email protected]> 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 [email protected] +49-172-7608481
Signature of: http://perl.plover.com/Questions.html
the second :
Randy Dunlap <[email protected]> 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.
Hi Jan :)
* Jan-Benedict Glaw <[email protected]> dixit:
> On Tue, 2007-06-26 12:16:39 +0200, DervishD <[email protected]> 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!
Hi Arne :)
* Arne Georg Gleditsch <[email protected]> dixit:
> Randy Dunlap <[email protected]> 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!
On Tue, 26 Jun 2007 17:33:59 +0200 DervishD wrote:
> Hi Jan :)
>
> * Jan-Benedict Glaw <[email protected]> dixit:
> > On Tue, 2007-06-26 12:16:39 +0200, DervishD <[email protected]> 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 ***
Hi Randy :)
* Randy Dunlap <[email protected]> dixit:
> On Tue, 26 Jun 2007 17:33:59 +0200 DervishD wrote:
> > * Jan-Benedict Glaw <[email protected]> dixit:
> > > On Tue, 2007-06-26 12:16:39 +0200, DervishD <[email protected]> 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!
On Tue, 26 Jun 2007 12:50:27 +0200 Arne Georg Gleditsch wrote:
> Randy Dunlap <[email protected]> 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 ***
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 <[email protected]>
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
Randy Dunlap <[email protected]> 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.