On Wed, Jul 31, 2013 at 05:07:26PM +0200, Dicebot wrote: > On Wednesday, 31 July 2013 at 14:58:24 UTC, H. S. Teoh wrote: > > People who are more than casually interested in computers should > > have at least some idea of what the underlying hardware is like. > > Otherwise the programs they write will be pretty weird. > > -- D. Knuth > > Well, while I do agree in general, there is a huge difference > between understanding how h/w executes machine code and casually > reading assembly listings ;)
I still find the ability to read machine code invaluable when debugging, esp. when trying to determine the cause of segfaults. At least at my day job, segfaults do log a stacktrace to a crash log, but there is no core dump, and on customer installations, there are no debugging symbols either, so all you have is a list of register values and stack return addresses. Being able to map that to the code by reading the disassembly of the executable allows you to pinpoint the cause of the problem, which otherwise would take many days of building and rebuilding test images, or worse, if the problem is only intermittent, it might take 5 months before QA is able to reproduce the problem reliably. In the past month or so, I've fixed at least two bugs this way, one of which only happens in a very specific network congestion state that it's pretty much impossible to reproduce without knowing what the problem was. Reading the disassembly allowed me to determine exactly which statement was dereferencing a null pointer, so that later, when I was tracing through the execution path, I immediately recognized a particular race condition that would trigger the precise symptoms I observed. Plus, I've identified the cause of a handful DMD wrong-code bugs by reading the disassembly of said wrong code. ;-) It's a pity I don't have the time to familiarize myself with DMD internals, otherwise I'd submit bug fixes too. T -- "You know, maybe we don't *need* enemies." "Yeah, best friends are about all I can take." -- Calvin & Hobbes
