On Mon, 23 Feb 2015 16:46:34 -0600 "T.J. Duchene" <t.j.duch...@gmail.com> wrote:
> > > > My philosopher as a free software author is this: The buck stops > > with me. If my software screws up, it's my fault and my > > responsibility to fix, regardless of the actual root cause is in > > code I wrote or a tool I use. > > > > If I were having problems with two different compilers treating my > > code two different ways, I'd #ifdef the hell out of it to kludge it > > back to working order on both. > > > > But that's just me. I've seen a lot of free software authors say > > "hey, it's not my fault, it's the ______ library or tool. Doesn't > > help the user a heck of a lot. > > > > SteveT > > > > That's a fair point, in an overall sense, Steve. I'm afraid as a > matter of practicality, I must disagree. > > Debugging on a compiler is a very specific skill-set. Asking someone > who doesn't do that every day to fix what is probably a compiler bug > is asking a lot - especially when you may have to venture into the > realm of processor mnemonics and specific registers to fix the > problem. > > In my opinion, that is especially relevant when dealing with ARM > because there are so many makers of ARM processors with specific > tweaks. > > T.J. Ahhh, now we're in my turf: Troubleshooting. If ARM restricts your choice of compilers, then I'll agree with you vis-a-vis ARM, sort of. For the wider application of my philosophy, it's amazing how little subject matter expertise (in this case tracing a compiler all the way down to instructions and registers) one needs in order to troubleshoot very effectively. Just as one example, in my classes I teach the power of having one system malfunctioning and one not malfunctioning. You can continue making each like the other until you can toggle the symptom with one statement. I call it "exploit the differences", and it's very powerful. So, let's say that I can narrow it down to (just to pull an imaginary example out of the air) clang crashing on memset() while gcc doesn't. Obviously, I'd better be sure the locale is the same on both. The next step could be writing a simplest case that does nothing but a memset, and see if it still crashes on memset(). If so, then I could write my own memset, and see if that crashes, and investigate why. Eventually perhaps, on clang, I could ifdef in my own memset(). Or, if I have the skills, I could trace memset into assembler. Perhaps a single memset wouldn't reproduce the symptom. I can then keep reducing the program until I get the smallest program that can reproduce the symptom, and experiment with that. And of course, the most likely scenario will be that it's *my* bad code, not the compilers, but even if I can prove it's the compiler's, I can work around it while I wait for the compiler guys to fix their compiler now that I've reported the problem. When I find a situation of unexpected behavior with a library or tool, I usually just work around it and report it to the library devs. The last thing the user needs is me and the library devs pointing fingers at each other. SteveT Steve Litt * http://www.troubleshooters.com/ Troubleshooting Training * Human Performance _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
