On Mon, 23 Feb 2015 16:46:34 -0600
"T.J. Duchene" <t.j.duchene@???> 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