** Reply to message from Christine Ames on Tue, 4
Dec 2001 18:06:59 -0800
> Many readers may be wondering why the kernel does not have any more advanced
> debugging features built into it. The answer, quite simply, is that Linus
> does not believe in interactive debuggers. He fears that they lead to poor
> fixes, those which patch up symptoms rather than addressing the real cause
> of problems. Thus, no built-in debuggers.
This has to be one of the dumbest statements I’ve ever read in connection with
device driver development. Fortunately, even if Linus is right and we’re all
wrong, we still have the stone knives and bearskins technique of DbgPrint!
Here’s another great quote from that page that I really enjoyed:
“The last resort in debugging modules is using a debugger to step through the
code, watching the value of variables and machine registers. This approach is
time-consuming and should be avoided whenever possible. Nonetheless, the
fine-grained perspective on the code that is achieved through a debugger is
sometimes invaluable.”
Wanting to watch variables or registers — what nerve! God help me, I’ve
even CHANGED registers under debug! How about this one:
“…a number of common capabilities provided by user-space debuggers, such as
breakpoints and single-stepping, are harder to come by in the kernel.”
Silly, silly me for using such last resort tools as Soft-ICE, KDB, ICAT
(OS/2), Periscope/32, and even Turbo Debugger back on DOS for all these years!
Sincerely,
Chris Myers
Senior Project Engineer
Quatech, Inc.
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Uh, well, that’s crap (what Torvalds thinks about debuggers.) Writing a
bunch of one time code to unit test software is nonsense. This is just
another example of irrational luddite conservatism, mixed in with an
unhealthy dose of ‘cult of personalty’ fascism in geekdom. “Linus says”,
sheesh.
But doesn’t numega sell a debugger? You really think it hasn’t much value?
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, December 05, 2001 10:03 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
I believe Linus’s point was that if you have the source code, you can do
more than just single step through code. For example, you can insert your
own probes into the kernel, recompile it, and at least in theory you would
have a much more accurate diagnostic of what’s going on. Instead of single
stepping to see if this or that happens, just add code to the kernel to do
it for you. If I remember correctly, when asked about debugging, he told
someone, “use the source, dude”, and I can see the point. But I’m not
radical about it, using a debugger is often a good idea. But maybe
single-stepping is a bit overrated, I don’t know.
Alberto.
-----Original Message-----
From: Jim Young [mailto:xxxxx@youngendeavors.com]
Sent: Tuesday, December 04, 2001 10:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
See, all you NT driver developers, things could be worse 
Seriously, relying solely on symbolic debuggers to remedy a poorly designed
driver will alway lead to less than desired results. On the other hand…
Jim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Christine Ames
Sent: Tuesday, December 04, 2001 6:07 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com
mailto:xxxxx ]
> Sent: Tuesday, December 04, 2001 3:29 PM
> BTW, Christine, can you recommend a kernel debugger for Linux?
>
Linux kernel developers are discouraged from using debuggers, however you
can use gdb and kdb.
Debugging techniques (including the use of kdb) are discussed here:
http://www.xml.com/ldd/chapter/book/ch04.html
http:
Note, however, the following quote from the above reference:
“The kdb Kernel Debugger
Many readers may be wondering why the kernel does not have any more advanced
debugging features built into it. The answer, quite simply, is that Linus
does not believe in interactive debuggers. He fears that they lead to poor
fixes, those which patch up symptoms rather than addressing the real cause
of problems. Thus, no built-in debuggers.
Other kernel developers, however, see an occasional use for interactive
debugging tools. One such tool is the kdb built-in kernel debugger,
available as a nonofficial patch from oss.sgi.com. To use kdb, you must
obtain the patch (be sure to get a version that matches your kernel
version), apply it, and rebuild and reinstall the kernel. Note that, as of
this writing, kdb works only on IA-32 (x86) systems (though a version for
the IA-64 existed for a while in the mainline kernel source before being
removed).”
Harmony,
Christine
—
You are currently subscribed to ntdev as: xxxxx@youngendeavors.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></mailto:xxxxx>
MessageWhat’s worse, ignoring for a moment the argument about debugger vs
dbgprints, is that Debug Prints can affect the system in unintended ways.
For example:
#if DEBUG
balah blah blah
ErrorCount++;
blah blah blah
#endif
Ever have that happen to you? Works in debug, but not release?
Greg
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, December 05, 2001 9:18 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
Uh, well, that’s crap (what Torvalds thinks about debuggers.) Writing a
bunch of one time code to unit test software is nonsense. This is just
another example of irrational luddite conservatism, mixed in with an
unhealthy dose of ‘cult of personalty’ fascism in geekdom. “Linus says”,
sheesh.
But doesn’t numega sell a debugger? You really think it hasn’t much value?
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, December 05, 2001 10:03 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
I believe Linus’s point was that if you have the source code, you can do
more than just single step through code. For example, you can insert your
own probes into the kernel, recompile it, and at least in theory you would
have a much more accurate diagnostic of what’s going on. Instead of single
stepping to see if this or that happens, just add code to the kernel to do
it for you. If I remember correctly, when asked about debugging, he told
someone, “use the source, dude”, and I can see the point. But I’m not
radical about it, using a debugger is often a good idea. But maybe
single-stepping is a bit overrated, I don’t know.
Alberto.
-----Original Message-----
From: Jim Young [mailto:xxxxx@youngendeavors.com]
Sent: Tuesday, December 04, 2001 10:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
See, all you NT driver developers, things could be worse
Seriously, relying solely on symbolic debuggers to remedy a poorly
designed driver will alway lead to less than desired results. On the other
hand…
Jim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Christine Ames
Sent: Tuesday, December 04, 2001 6:07 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
-----Original Message-----
> From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> Sent: Tuesday, December 04, 2001 3:29 PM
> BTW, Christine, can you recommend a kernel debugger for Linux?
>
Linux kernel developers are discouraged from using debuggers,
however you can use gdb and kdb.
Debugging techniques (including the use of kdb) are discussed here:
http://www.xml.com/ldd/chapter/book/ch04.html
Note, however, the following quote from the above reference:
“The kdb Kernel Debugger
Many readers may be wondering why the kernel does not have any more
advanced debugging features built into it. The answer, quite simply, is that
Linus does not believe in interactive debuggers. He fears that they lead to
poor fixes, those which patch up symptoms rather than addressing the real
cause of problems. Thus, no built-in debuggers.
Other kernel developers, however, see an occasional use for
interactive debugging tools. One such tool is the kdb built-in kernel
debugger, available as a nonofficial patch from oss.sgi.com. To use kdb, you
must obtain the patch (be sure to get a version that matches your kernel
version), apply it, and rebuild and reinstall the kernel. Note that, as of
this writing, kdb works only on IA-32 (x86) systems (though a version for
the IA-64 existed for a while in the mainline kernel source before being
removed).”
Harmony,
Christine
—
You are currently subscribed to ntdev as: xxxxx@youngendeavors.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as:
xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You guys miss the point. It’s not about adding code to the driver, it’s
adding code to the kernel. The attitude is that while the driver is a
potential production thing, company property, source control, and all that
cool jazz, the kernel belongs to the developer, runs in the developer’s
target machine and can be recompiled a zillion times a day and changed up
and down according to the developer’s whims. Did it affect the system in
unintended ways ? Go back to the drawing board, do the job right, fix the
problem - but the kernel’s not going to be shipped with the driver, so, any
change to the kernel stays inside that target machine. It’s not just about
debugprints, it’s about a lot more. The attitude is also that “the system”
isn’t some sacred dogpile that can’t be touched, but rather that the kernel
is just a tool, like anything else, more, that tool can be reconfigured and
adapted, on the fly if need be, to the needs of the developer. I like that,
the good old concept that it’s I myself who’s in charge, not the OS.
Alberto.
-----Original Message-----
From: Gregory G. Dyess [mailto:xxxxx@pdq.net]
Sent: Wednesday, December 05, 2001 10:53 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
What’s worse, ignoring for a moment the argument about debugger vs
dbgprints, is that Debug Prints can affect the system in unintended ways.
For example:
#if DEBUG
balah blah blah
ErrorCount++;
blah blah blah
#endif
Ever have that happen to you? Works in debug, but not release?
Greg
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, December 05, 2001 9:18 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
Uh, well, that’s crap (what Torvalds thinks about debuggers.) Writing a
bunch of one time code to unit test software is nonsense. This is just
another example of irrational luddite conservatism, mixed in with an
unhealthy dose of ‘cult of personalty’ fascism in geekdom. “Linus says”,
sheesh.
But doesn’t numega sell a debugger? You really think it hasn’t much value?
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, December 05, 2001 10:03 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
I believe Linus’s point was that if you have the source code, you can do
more than just single step through code. For example, you can insert your
own probes into the kernel, recompile it, and at least in theory you would
have a much more accurate diagnostic of what’s going on. Instead of single
stepping to see if this or that happens, just add code to the kernel to do
it for you. If I remember correctly, when asked about debugging, he told
someone, “use the source, dude”, and I can see the point. But I’m not
radical about it, using a debugger is often a good idea. But maybe
single-stepping is a bit overrated, I don’t know.
Alberto.
-----Original Message-----
From: Jim Young [mailto:xxxxx@youngendeavors.com]
Sent: Tuesday, December 04, 2001 10:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
See, all you NT driver developers, things could be worse
Seriously, relying solely on symbolic debuggers to remedy a poorly designed
driver will alway lead to less than desired results. On the other hand…
Jim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Christine Ames
Sent: Tuesday, December 04, 2001 6:07 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
-----Original Message-----
From: Maxim S. Shatskih [ mailto:xxxxx@storagecraft.com
mailto:xxxxx ]
> Sent: Tuesday, December 04, 2001 3:29 PM
> BTW, Christine, can you recommend a kernel debugger for Linux?
>
Linux kernel developers are discouraged from using debuggers, however you
can use gdb and kdb.
Debugging techniques (including the use of kdb) are discussed here:
http://www.xml.com/ldd/chapter/book/ch04.html
http:
Note, however, the following quote from the above reference:
“The kdb Kernel Debugger
Many readers may be wondering why the kernel does not have any more advanced
debugging features built into it. The answer, quite simply, is that Linus
does not believe in interactive debuggers. He fears that they lead to poor
fixes, those which patch up symptoms rather than addressing the real cause
of problems. Thus, no built-in debuggers.
Other kernel developers, however, see an occasional use for interactive
debugging tools. One such tool is the kdb built-in kernel debugger,
available as a nonofficial patch from oss.sgi.com. To use kdb, you must
obtain the patch (be sure to get a version that matches your kernel
version), apply it, and rebuild and reinstall the kernel. Note that, as of
this writing, kdb works only on IA-32 (x86) systems (though a version for
the IA-64 existed for a while in the mainline kernel source before being
removed).”
Harmony,
Christine
—
You are currently subscribed to ntdev as: xxxxx@youngendeavors.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></mailto:xxxxx>
Oh please Jim, that is pure arrogance,
So you have a perfectly perfected performing driver but you’re a piss poor
typist and use “=” instead of “==” in a clause. The only one that never
needs a debugger is the one that writes perfect code. And we tend to nail
them to trees. You don’t use debuggers to “remedy poorly designed code”. You
use debuggers to find out WHY your properly designed code ain’t working
Linus needs to snatch his blankie back from Snoopie and go take a nap.
Gary G. Little
Broadband Storage, Inc.
xxxxx@broadstor.com
xxxxx@inland.net
(949) 7372731
-----Original Message-----
From: Jim Young [mailto:xxxxx@youngendeavors.com]
Sent: Tuesday, December 04, 2001 7:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
See, all you NT driver developers, things could be worse
Seriously, relying solely on symbolic debuggers to remedy a poorly designed
driver will alway lead to less than desired results. On the other hand…
Jim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Christine Ames
Sent: Tuesday, December 04, 2001 6:07 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
-----Original Message-----
From: Maxim S. Shatskih [ mailto:xxxxx@storagecraft.com
mailto:xxxxx ]
> Sent: Tuesday, December 04, 2001 3:29 PM
> BTW, Christine, can you recommend a kernel debugger for Linux?
>
Linux kernel developers are discouraged from using debuggers, however you
can use gdb and kdb.
Debugging techniques (including the use of kdb) are discussed here:
http://www.xml.com/ldd/chapter/book/ch04.html
http:
Note, however, the following quote from the above reference:
“The kdb Kernel Debugger
Many readers may be wondering why the kernel does not have any more advanced
debugging features built into it. The answer, quite simply, is that Linus
does not believe in interactive debuggers. He fears that they lead to poor
fixes, those which patch up symptoms rather than addressing the real cause
of problems. Thus, no built-in debuggers.
Other kernel developers, however, see an occasional use for interactive
debugging tools. One such tool is the kdb built-in kernel debugger,
available as a nonofficial patch from oss.sgi.com. To use kdb, you must
obtain the patch (be sure to get a version that matches your kernel
version), apply it, and rebuild and reinstall the kernel. Note that, as of
this writing, kdb works only on IA-32 (x86) systems (though a version for
the IA-64 existed for a while in the mainline kernel source before being
removed).”
Harmony,
Christine
—
You are currently subscribed to ntdev as: xxxxx@youngendeavors.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></mailto:xxxxx>
I don’t care where you are adding throwaway useless debugging code, it is
throwaway useless debugging code. If there is a tool that can do the same
thing (and more) without modifying the source code at all, saving me time
and effort, I shouldn’t use this tool because why? Because some God of the
Penguins says it is BAD? Is there a rational reason here? All I’ve seen is
some assertion (not supported by any argument) that somehow using a debugger
causes or is correlated with poor code, while adding a lot of throw away
diagnostics causes or is correlated with good code. Do we have some metrics
on that? Some study by the process freaks? An ACM or IEEE article?
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, December 05, 2001 11:07 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
You guys miss the point. It’s not about adding code to the driver, it’s
adding code to the kernel. The attitude is that while the driver is a
potential production thing, company property, source control, and all that
cool jazz, the kernel belongs to the developer, runs in the developer’s
target machine and can be recompiled a zillion times a day and changed up
and down according to the developer’s whims. Did it affect the system in
unintended ways ? Go back to the drawing board, do the job right, fix the
problem - but the kernel’s not going to be shipped with the driver, so, any
change to the kernel stays inside that target machine. It’s not just about
debugprints, it’s about a lot more. The attitude is also that “the system”
isn’t some sacred dogpile that can’t be touched, but rather that the kernel
is just a tool, like anything else, more, that tool can be reconfigured and
adapted, on the fly if need be, to the needs of the developer. I like that,
the good old concept that it’s I myself who’s in charge, not the OS.
Alberto.
-----Original Message-----
From: Gregory G. Dyess [mailto:xxxxx@pdq.net]
Sent: Wednesday, December 05, 2001 10:53 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
What’s worse, ignoring for a moment the argument about debugger vs
dbgprints, is that Debug Prints can affect the system in unintended ways.
For example:
#if DEBUG
balah blah blah
ErrorCount++;
blah blah blah
#endif
Ever have that happen to you? Works in debug, but not release?
Greg
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Wednesday, December 05, 2001 9:18 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
Uh, well, that’s crap (what Torvalds thinks about debuggers.) Writing a
bunch of one time code to unit test software is nonsense. This is just
another example of irrational luddite conservatism, mixed in with an
unhealthy dose of ‘cult of personalty’ fascism in geekdom. “Linus says”,
sheesh.
But doesn’t numega sell a debugger? You really think it hasn’t much value?
-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, December 05, 2001 10:03 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
I believe Linus’s point was that if you have the source code, you can do
more than just single step through code. For example, you can insert your
own probes into the kernel, recompile it, and at least in theory you would
have a much more accurate diagnostic of what’s going on. Instead of single
stepping to see if this or that happens, just add code to the kernel to do
it for you. If I remember correctly, when asked about debugging, he told
someone, “use the source, dude”, and I can see the point. But I’m not
radical about it, using a debugger is often a good idea. But maybe
single-stepping is a bit overrated, I don’t know.
Alberto.
-----Original Message-----
From: Jim Young [mailto:xxxxx@youngendeavors.com]
Sent: Tuesday, December 04, 2001 10:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
See, all you NT driver developers, things could be worse
Seriously, relying solely on symbolic debuggers to remedy a poorly designed
driver will alway lead to less than desired results. On the other hand…
Jim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Christine Ames
Sent: Tuesday, December 04, 2001 6:07 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com
mailto:xxxxx ]
> Sent: Tuesday, December 04, 2001 3:29 PM
> BTW, Christine, can you recommend a kernel debugger for Linux?
>
Linux kernel developers are discouraged from using debuggers, however you
can use gdb and kdb.
Debugging techniques (including the use of kdb) are discussed here:
http://www.xml.com/ldd/chapter/book/ch04.html
http:
Note, however, the following quote from the above reference:
“The kdb Kernel Debugger
Many readers may be wondering why the kernel does not have any more advanced
debugging features built into it. The answer, quite simply, is that Linus
does not believe in interactive debuggers. He fears that they lead to poor
fixes, those which patch up symptoms rather than addressing the real cause
of problems. Thus, no built-in debuggers.
Other kernel developers, however, see an occasional use for interactive
debugging tools. One such tool is the kdb built-in kernel debugger,
available as a nonofficial patch from oss.sgi.com. To use kdb, you must
obtain the patch (be sure to get a version that matches your kernel
version), apply it, and rebuild and reinstall the kernel. Note that, as of
this writing, kdb works only on IA-32 (x86) systems (though a version for
the IA-64 existed for a while in the mainline kernel source before being
removed).”
Harmony,
Christine
—
You are currently subscribed to ntdev as: xxxxx@youngendeavors.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@pdq.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></mailto:xxxxx>
RE: [ntdev] RE: Global variablesGary, I couldn’t agree with you more. I’m
surprised that you found my statement arrogant.
Jim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Gary Little
Sent: Wednesday, December 05, 2001 8:21 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
Oh please Jim, that is pure arrogance,
So you have a perfectly perfected performing driver but you’re a piss poor
typist and use “=” instead of “==” in a clause. The only one that never
needs a debugger is the one that writes perfect code. And we tend to nail
them to trees. You don’t use debuggers to “remedy poorly designed code”. You
use debuggers to find out WHY your properly designed code ain’t working
Linus needs to snatch his blankie back from Snoopie and go take a nap.
Gary G. Little
Broadband Storage, Inc.
(949) 7372731
-----Original Message-----
From: Jim Young [mailto:xxxxx@youngendeavors.com]
Sent: Tuesday, December 04, 2001 7:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
See, all you NT driver developers, things could be worse
Seriously, relying solely on symbolic debuggers to remedy a poorly
designed driver will alway lead to less than desired results. On the other
hand…
Jim
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Christine Ames
Sent: Tuesday, December 04, 2001 6:07 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
-----Original Message-----
> From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> Sent: Tuesday, December 04, 2001 3:29 PM
> BTW, Christine, can you recommend a kernel debugger for Linux?
>
Linux kernel developers are discouraged from using debuggers, however you
can use gdb and kdb.
Debugging techniques (including the use of kdb) are discussed here:
http://www.xml.com/ldd/chapter/book/ch04.html
Note, however, the following quote from the above reference:
“The kdb Kernel Debugger
Many readers may be wondering why the kernel does not have any more
advanced debugging features built into it. The answer, quite simply, is that
Linus does not believe in interactive debuggers. He fears that they lead to
poor fixes, those which patch up symptoms rather than addressing the real
cause of problems. Thus, no built-in debuggers.
Other kernel developers, however, see an occasional use for interactive
debugging tools. One such tool is the kdb built-in kernel debugger,
available as a nonofficial patch from oss.sgi.com. To use kdb, you must
obtain the patch (be sure to get a version that matches your kernel
version), apply it, and rebuild and reinstall the kernel. Note that, as of
this writing, kdb works only on IA-32 (x86) systems (though a version for
the IA-64 existed for a while in the mainline kernel source before being
removed).”
Harmony,
Christine
—
You are currently subscribed to ntdev as: xxxxx@youngendeavors.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: xxxxx@youngendeavors.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> -----Original Message-----
From: Stephen Williams [mailto:xxxxx@icarus.com]
Sent: Tuesday, December 04, 2001 4:26 PMxxxxx@PacificDigital.com said:
> I experimented with this (under 2.4.7) and my module global
variables
> showed up in /proc/ksyms without being explicitly exported.?
I’ve only
> been writing drivers for Linux for a few months, but I
thought /proc/
> ksyms was global to the entire kernel?? Am I missing something?if you do nothing at all with the symbols, then the default is to
add all the external symbols to the kernel symbol table. If you do
anything explicit with export management, it reverts to doing exactly
what is requested.This is compatibility behavior.
Thanks a lot, Steve!
–Christine
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> -----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Tuesday, December 04, 2001 7:25 PM
> Which confirms my unhappy opinion of linux.
Now, now, now. I’m lucky enough to have been involved with drivers for both
Windows and Linux. Each OS has their good side and their bad side.
Harmony,
Christine
> -----Original Message-----
> From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Christine Ames
> Sent: Tuesday, December 04, 2001 9:07 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Global variables
>
>
> > -----Original Message-----
> > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> > Sent: Tuesday, December 04, 2001 3:29 PM
>
> > BTW, Christine, can you recommend a kernel debugger for Linux?
> >
> Linux kernel developers are discouraged from using debuggers, however you
can use gdb and kdb.
> Debugging techniques (including the use of kdb) are discussed here:
http://www.xml.com/ldd/chapter/book/ch04.html
> Note, however, the following quote from the above reference:
> “The kdb Kernel Debugger
> Many readers may be wondering why the kernel does not have any more
advanced debugging features built into it. The answer, > quite simply, is
that Linus does not believe in interactive debuggers. He fears that they
lead to poor fixes, those which
> patch up symptoms rather than addressing the real cause of problems. Thus,
no built-in debuggers.
> Other kernel developers, however, see an occasional use for interactive
debugging tools. One such tool is the kdb built-in > kernel debugger,
available as a nonofficial patch from oss.sgi.com. To use kdb, you must
obtain the patch (be sure to get a > version that matches your kernel
version), apply it, and rebuild and reinstall the kernel. Note that, as of
this writing,
> kdb works only on IA-32 (x86) systems (though a version for the IA-64
existed for a while in the mainline kernel source
> before being removed).”
> Harmony,
> Christine
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> -----Original Message-----
From: Phillip Susi [mailto:xxxxx@cfl.rr.com]
Sent: Tuesday, December 04, 2001 8:16 PM
> Anyhow, I found a really neat linux kernel debugger called
> private ice,
> that is like softice, but it doesn’t seem to be maintained that
> much. Iirc, it was at http://pice.sourceforge.net.
>
YO! Thanks, Dude.
–Christine
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
It’s just that Linus’s blankie has more holes in it than do Bills.
Gary G. Little
Broadband Storage, Inc.
xxxxx@broadstor.com
xxxxx@inland.net
(949) 7372731
-----Original Message-----
From: Christine Ames [mailto:xxxxx@PacificDigital.com]
Sent: Wednesday, December 05, 2001 9:49 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
-----Original Message-----
From: Mark Roddy [ mailto:xxxxx@hollistech.com
mailto:xxxxx ]
> Sent: Tuesday, December 04, 2001 7:25 PM
>
> Which confirms my unhappy opinion of linux.
Now, now, now. I’m lucky enough to have been involved with drivers for both
Windows and Linux. Each OS has their good side and their bad side.
Harmony,
Christine
> -----Original Message-----
> From: xxxxx@lists.osr.com [
mailto:xxxxx@lists.osr.com
mailto:xxxxx] On Behalf Of Christine Ames
> Sent: Tuesday, December 04, 2001 9:07 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Global variables
>
>
> > -----Original Message-----
> > From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com
mailto:xxxxx]
> > Sent: Tuesday, December 04, 2001 3:29 PM
>
> > BTW, Christine, can you recommend a kernel debugger for Linux?
> >
> Linux kernel developers are discouraged from using debuggers, however you
can use gdb and kdb.
> Debugging techniques (including the use of kdb) are discussed here:
http://www.xml.com/ldd/chapter/book/ch04.html
http:
> Note, however, the following quote from the above reference:
> “The kdb Kernel Debugger
> Many readers may be wondering why the kernel does not have any more
advanced debugging features built into it. The answer, > quite simply, is
that Linus does not believe in interactive debuggers. He fears that they
lead to poor fixes, those which
> patch up symptoms rather than addressing the real cause of problems. Thus,
no built-in debuggers.
> Other kernel developers, however, see an occasional use for interactive
debugging tools. One such tool is the kdb built-in > kernel debugger,
available as a nonofficial patch from oss.sgi.com. To use kdb, you must
obtain the patch (be sure to get a > version that matches your kernel
version), apply it, and rebuild and reinstall the kernel. Note that, as of
this writing,
> kdb works only on IA-32 (x86) systems (though a version for the IA-64
existed for a while in the mainline kernel source
> before being removed).”
> Harmony,
> Christine
—
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>
Maybe the original assertion isn’t so stupid as it seems:
The answer, quite simply, is that Linus does not believe in interactive
debuggers. He fears that they lead to poor fixes, those which patch up
symptoms rather than addressing the real cause of problems. Thus, no
built-in debuggers.
This is not about one driver which is usual case of NT kernel development
but (IMO) about whole kernel development. Find a problem using a debugger is
usually easier; it is possible to find it even if you don’t really
understand how things work. This can really lead to fix symptoms instead of
real cause. On the other hand finding a problem using traces and source code
only is tedious. It needs better understanding but also gives more complete
picture. Maybe that’s the reason – discourage people with no real
understanding from “fixing” kernel. Well, maybe we should ask Linus about
the reasoning instead 
Personally, I use both debugger and traces and even write throwaway useless
debugging code sometimes. There are cases when debugger influences
processing too much. Never seen the problem which is reproducible but only
if code isn’t traced? Never met race conditions which are only reproducible
in real time, once per week? Yes, a debug assert at proper place which
awakes debugger helps but at first it is necessary to find this proper
place.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
I don’t care where you are adding throwaway useless debugging code, it is
throwaway useless debugging code. If there is a tool that can do the same
thing (and more) without modifying the source code at all, saving me time
and effort, I shouldn’t use this tool because why? Because some God of the
Penguins says it is BAD? Is there a rational reason here? All I’ve seen is
some assertion (not supported by any argument) that somehow using a
debugger causes or is correlated with poor code, while adding a lot of
throw away diagnostics causes or is correlated with good code. Do we have
some metrics on that? Some study by the process freaks? An ACM or IEEE
article?-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, December 05, 2001 11:07 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variablesYou guys miss the point. It’s not about adding code to the driver,
it’s adding code to the kernel. The attitude is that while the driver is a
potential production thing, company property, source control, and all that
cool jazz, the kernel belongs to the developer, runs in the developer’s
target machine and can be recompiled a zillion times a day and changed up
and down according to the developer’s whims. Did it affect the system in
unintended ways ? Go back to the drawing board, do the job right, fix the
problem - but the kernel’s not going to be shipped with the driver, so,
any change to the kernel stays inside that target machine. It’s not just
about debugprints, it’s about a lot more. The attitude is also that “the
system” isn’t some sacred dogpile that can’t be touched, but rather that
the kernel is just a tool, like anything else, more, that tool can be
reconfigured and adapted, on the fly if need be, to the needs of the
developer. I like that, the good old concept that it’s I myself who’s in
charge, not the OS.Alberto.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
I’ve got into more than one case where the problem went away the moment I
installed SoftICE in the machine. Race conditions sometimes behave that way.
When I did Win9x drivers, in machine code, clobbering a register that should
be preserved made it rather hard to figure things out, because again, the
presence of the debugger would change the context of the problem. I agree
with you, there’s a case for both techniques. Also, if you want to trap that
one intermittent WHQL failure that happens towards the 6th hour of a 10 hour
stress test, you need more than a debugger: you may need a bounds checker. I
remember I had a case where one of my OpenGL fog primitives was one color
slot off, for example, this one pixel would have a red component of 1.0
instead of 2.0 as the test required, and only intermittently - worse, the
test drew the window at different locations on the screen, and only one of
those locations ever showed the problem. In these cases, there’s no way I
was going to find out the problem without writing specific code to detect
it, and the chances of anyone without the source code to solve the issue
were close to nil.
Alberto.
-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@veridicom.cz.nospam]
Sent: Wednesday, December 05, 2001 3:30 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
Maybe the original assertion isn’t so stupid as it seems:
The answer, quite simply, is that Linus does not believe in interactive
debuggers. He fears that they lead to poor fixes, those which patch up
symptoms rather than addressing the real cause of problems. Thus, no
built-in debuggers.
This is not about one driver which is usual case of NT kernel development
but (IMO) about whole kernel development. Find a problem using a debugger is
usually easier; it is possible to find it even if you don’t really
understand how things work. This can really lead to fix symptoms instead of
real cause. On the other hand finding a problem using traces and source code
only is tedious. It needs better understanding but also gives more complete
picture. Maybe that’s the reason – discourage people with no real
understanding from “fixing” kernel. Well, maybe we should ask Linus about
the reasoning instead
Personally, I use both debugger and traces and even write throwaway useless
debugging code sometimes. There are cases when debugger influences
processing too much. Never seen the problem which is reproducible but only
if code isn’t traced? Never met race conditions which are only reproducible
in real time, once per week? Yes, a debug assert at proper place which
awakes debugger helps but at first it is necessary to find this proper
place.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Gary,
is isn’t the best example. “=” versus “==” problems should be found during
driver build, not in runtime. If compiler doesn’t warn about it, lint does.
Tracing such problems is tedious even using a debugger; don’t know about you
but if I write something like this and don’t see a bug immediately, notice
it only when switch to assembly and see unexpected mov to a variable
Nobody writes perfect code but bugs can be always find using other
techniques. Debugger only makes it easier, usually.
Note I have nothing against debuggers, you know I do like SoftICE
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
Oh please Jim, that is pure arrogance,
So you have a perfectly perfected performing driver but you’re a piss poor
typist and use “=” instead of “==” in a clause. The only one that never
needs a debugger is the one that writes perfect code. And we tend to nail
them to trees. You don’t use debuggers to “remedy poorly designed code”.
You use debuggers to find out WHY your properly designed code ain’t
workingLinus needs to snatch his blankie back from Snoopie and go take a nap.
Gary G. Little
Broadband Storage, Inc.
xxxxx@broadstor.com
xxxxx@inland.net
(949) 7372731-----Original Message-----
From: Jim Young [mailto:xxxxx@youngendeavors.com]
Sent: Tuesday, December 04, 2001 7:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variablesSee, all you NT driver developers, things could be worse
Seriously, relying solely on symbolic debuggers to remedy a poorly
designed driver will alway lead to less than desired results. On the other
hand…Jim
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> ----------
From:
xxxxx@compuware.com[SMTP:xxxxx@compuware.com]
Reply To: xxxxx@lists.osr.com
Sent: Wednesday, December 05, 2001 9:41 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] RE: Global variablesI’ve got into more than one case where the problem went away the moment I
installed SoftICE in the machine. Race conditions sometimes behave that
way.
When I did Win9x drivers, in machine code, clobbering a register that
should
be preserved made it rather hard to figure things out, because again, the
presence of the debugger would change the context of the problem.
Next example is uninitialized stack variable. When code runs normally,
unused stack contains results of previous computation and when traced,
debugger rewrites unused stack. A function is called, uninitialized pointer
is used and accidentally contains an address of other variable which is
mysteriously rewritten. Debugger covers the problem because uninitialized
pointer contains something else now.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
It looks to me you have come closest to the real reason for this
setup with a poor kernel debugger. It is likely designed to scare
away those “need to get Linux driver done in two weeks please tell
me how to compile it says syntax error” folks. The point is that
before you write kernel-mode code you study carefully all of the code
that will surround it until you completely understand what it does.
Microsoft too might want to scare those away, but they can’t offer
people to resort to the source code.
— Michal Vodicka wrote:
> Maybe the original assertion isn’t so stupid as it seems:
>
> > The answer, quite simply, is that Linus does not believe in interactive
> > debuggers. He fears that they lead to poor fixes, those which patch up
> > symptoms rather than addressing the real cause of problems. Thus, no
> > built-in debuggers.
> >
> This is not about one driver which is usual case of NT kernel development
> but (IMO) about whole kernel development. Find a problem using a debugger is
> usually easier; it is possible to find it even if you don’t really
> understand how things work. This can really lead to fix symptoms instead of
> real cause. On the other hand finding a problem using traces and source code
> only is tedious. It needs better understanding but also gives more complete
> picture. Maybe that’s the reason – discourage people with no real
> understanding from “fixing” kernel. Well, maybe we should ask Linus about
> the reasoning instead
>
> Personally, I use both debugger and traces and even write throwaway useless
> debugging code sometimes. There are cases when debugger influences
> processing too much. Never seen the problem which is reproducible but only
> if code isn’t traced? Never met race conditions which are only reproducible
> in real time, once per week? Yes, a debug assert at proper place which
> awakes debugger helps but at first it is necessary to find this proper
> place.
>
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
> > ----------
> >
> > I don’t care where you are adding throwaway useless debugging code, it is
> > throwaway useless debugging code. If there is a tool that can do the same
> > thing (and more) without modifying the source code at all, saving me time
> > and effort, I shouldn’t use this tool because why? Because some God of the
> > Penguins says it is BAD? Is there a rational reason here? All I’ve seen is
> > some assertion (not supported by any argument) that somehow using a
> > debugger causes or is correlated with poor code, while adding a lot of
> > throw away diagnostics causes or is correlated with good code. Do we have
> > some metrics on that? Some study by the process freaks? An ACM or IEEE
> > article?
> >
> > -----Original Message-----
> > From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> > Sent: Wednesday, December 05, 2001 11:07 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Global variables
> >
> >
> >
> > You guys miss the point. It’s not about adding code to the driver,
> > it’s adding code to the kernel. The attitude is that while the driver is a
> > potential production thing, company property, source control, and all that
> > cool jazz, the kernel belongs to the developer, runs in the developer’s
> > target machine and can be recompiled a zillion times a day and changed up
> > and down according to the developer’s whims. Did it affect the system in
> > unintended ways ? Go back to the drawing board, do the job right, fix the
> > problem - but the kernel’s not going to be shipped with the driver, so,
> > any change to the kernel stays inside that target machine. It’s not just
> > about debugprints, it’s about a lot more. The attitude is also that “the
> > system” isn’t some sacred dogpile that can’t be touched, but rather that
> > the kernel is just a tool, like anything else, more, that tool can be
> > reconfigured and adapted, on the fly if need be, to the needs of the
> > developer. I like that, the good old concept that it’s I myself who’s in
> > charge, not the OS.
> >
> > Alberto.
> >
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@yahoo.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Actually, I think it is. Given that what you want to do is:
if (V1 == Myfunction())
And instead you fat finger it and it comes out:
If ((V1= Myfunction()))
The compiler won’t catch it, I doubt that LINT will, and if it happens to be
in a seldom executed logic path, you have a bug standing in the wings you
don’t know about.
Gary G. Little
Broadband Storage, Inc.
xxxxx@broadstor.com
xxxxx@inland.net
(949) 7372731
-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@veridicom.cz.nospam]
Sent: Wednesday, December 05, 2001 12:44 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
Gary,
is isn’t the best example. “=” versus “==” problems should be found during
driver build, not in runtime. If compiler doesn’t warn about it, lint does.
Tracing such problems is tedious even using a debugger; don’t know about you
but if I write something like this and don’t see a bug immediately, notice
it only when switch to assembly and see unexpected mov to a variable
Nobody writes perfect code but bugs can be always find using other
techniques. Debugger only makes it easier, usually.
Note I have nothing against debuggers, you know I do like SoftICE
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
Oh please Jim, that is pure arrogance,
So you have a perfectly perfected performing driver but you’re a piss poor
typist and use “=” instead of “==” in a clause. The only one that never
needs a debugger is the one that writes perfect code. And we tend to nail
them to trees. You don’t use debuggers to “remedy poorly designed code”.
You use debuggers to find out WHY your properly designed code ain’t
workingLinus needs to snatch his blankie back from Snoopie and go take a nap.
Gary G. Little
Broadband Storage, Inc.
xxxxx@broadstor.com
xxxxx@inland.net
(949) 7372731-----Original Message-----
From: Jim Young [mailto:xxxxx@youngendeavors.com]
Sent: Tuesday, December 04, 2001 7:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variablesSee, all you NT driver developers, things could be worse
Seriously, relying solely on symbolic debuggers to remedy a poorly
designed driver will alway lead to less than desired results. On the other
hand…Jim
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Way back when, Wizard C detected this. It was a pain, because they’d force
you to write
if ((v1=Myfunction())!=0)
instead of the more compact
if (v1=Myfunction())
Their point was precisely that it’s more likely that the programmer really
meant “==”. Anyone knows if other non-Microsoft compilers do this kind of
checking ?
Alberto.
-----Original Message-----
From: Gary Little [mailto:xxxxx@Broadstor.com]
Sent: Wednesday, December 05, 2001 4:08 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
Actually, I think it is. Given that what you want to do is:
if (V1 == Myfunction())
And instead you fat finger it and it comes out:
If ((V1= Myfunction()))
The compiler won’t catch it, I doubt that LINT will, and if it happens to be
in a seldom executed logic path, you have a bug standing in the wings you
don’t know about.
Gary G. Little
Broadband Storage, Inc.
xxxxx@broadstor.com
xxxxx@inland.net
(949) 7372731
-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@veridicom.cz.nospam]
Sent: Wednesday, December 05, 2001 12:44 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
Gary,
is isn’t the best example. “=” versus “==” problems should be found during
driver build, not in runtime. If compiler doesn’t warn about it, lint does.
Tracing such problems is tedious even using a debugger; don’t know about you
but if I write something like this and don’t see a bug immediately, notice
it only when switch to assembly and see unexpected mov to a variable
Nobody writes perfect code but bugs can be always find using other
techniques. Debugger only makes it easier, usually.
Note I have nothing against debuggers, you know I do like SoftICE
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
Oh please Jim, that is pure arrogance,
So you have a perfectly perfected performing driver but you’re a piss poor
typist and use “=” instead of “==” in a clause. The only one that never
needs a debugger is the one that writes perfect code. And we tend to nail
them to trees. You don’t use debuggers to “remedy poorly designed code”.
You use debuggers to find out WHY your properly designed code ain’t
workingLinus needs to snatch his blankie back from Snoopie and go take a nap.
Gary G. Little
Broadband Storage, Inc.
xxxxx@broadstor.com
xxxxx@inland.net
(949) 7372731-----Original Message-----
From: Jim Young [mailto:xxxxx@youngendeavors.com]
Sent: Tuesday, December 04, 2001 7:21 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variablesSee, all you NT driver developers, things could be worse
Seriously, relying solely on symbolic debuggers to remedy a poorly
designed driver will alway lead to less than desired results. On the other
hand…Jim
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Another example, your code jumps to nevernever land because of a defective
pointer. That happens to be, say, in the middle of a data buffer. You load
SoftICE, and the buffer is no longer there, something else is, maybe a piece
of somebody else’s code, which does a couple of harmless register moves and
returns to the caller: the problem is masked away. Or not - in an extreme
case, we ended up jumping into SoftICE and crashing it!
Alberto.
-----Original Message-----
From: Michal Vodicka [mailto:xxxxx@veridicom.cz.nospam]
Sent: Wednesday, December 05, 2001 3:57 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Global variables
Next example is uninitialized stack variable. When code runs normally,
unused stack contains results of previous computation and when traced,
debugger rewrites unused stack. A function is called, uninitialized pointer
is used and accidentally contains an address of other variable which is
mysteriously rewritten. Debugger covers the problem because uninitialized
pointer contains something else now.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
xxxxx@compuware.com said:
Their point was precisely that it’s more likely that the programmer
really meant “==”. Anyone knows if other non-Microsoft compilers do
this kind of checking ?
gcc does.
if (a = b)
generates a warning. You can suppress the warning by writing:
if ((a = b))
Note the extra ().
–
Steve Williams “The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com