On 11/20/2010 1:05 PM, MK wrote:
I do not
think the exception (a need for debugging) should make the rule
(general use, production grade software). I'd bet 99%+ of the time
those compiled in debugging symbols never even get used a single time.
The black box on an airplane doesn't get much use, either. That's no
reason to strip (*cough*) it out, though is it? That would make
figuring out the cause of a crash much more difficult.
I don't need to connect the dots for you, do I?
much, much rather have it work in as streamlined a manner day to day,
*by default*, then if I run into a problem, I can build CFLAGS=-g to
diagnose.
That's great when your problems are easily reproducible.
One of the goals of a good software development process is to find and
fix all the easily reproducible bugs before binaries ship to customers.
If not on first release, certainly soon after.
Having achieved that, you're left with nothing but blue-moon crashers,
and there's nothing better for diagnosing the cause of such things than
a core dump.
Sometimes, though, a core dump doesn't tell you anything when you copy
it to your development station. You need to debug the problem in place.
If the debugging symbols are already present on the production system,
life is easy. (Well, as easy as debugging ever gets.)
If not, now you have to figure out how to build debug binaries in a
state exactly like how they shipped to that one customer, who, if you
have an agile development process, probably has a different version than
almost any other site, simply depending on when their system was last
upgraded. (If you can always upgrade every customer to the latest
version just to debug a problem, you must work in a very different
business environment than I find myself in.) If the rebuilt debug
binaries don't match the shipped binaries, the core dump will be
useless, because it will have pointers that refer to incorrect locations
in the new program text.
No doubt you have a good version numbering system so you can figure out
how to rebuild those binariesgiven maybe an hour or so. An hour you
probably don't have, because the customer is calling every ten minutes
wanting to know when you'll have their system back up. An hour you
could have spent debugging the problem in situ using the debugging
symbols you had the forethought to leave in the shipping binaries.
If I put a device in your car that ran the battery down and lowered the
gas mileage, the purpose of which was to diagnose problems *when there
aren't any*, then said you should leave it on all the time anyway, what
would you think?
Bad analogy.
Debugging symbols don't affect a program when it's sitting there not
running. You can't usefully compare this to a fictional car device that
runs the battery down when the car isn't running.
Such a device would necessarily take power when the car is running, and
conservation of energy being the inviolable law it is, it will reduce
your gas mileage slightly. (So does turning on the headlights, but you
wouldn't advocate leaving them off at night to improve gas mileage.)
The correct analogy is volume and weight: such a device takes room under
the dash somewhere and makes the car slightly heavier, even when the car
isn't running. Big deal.
Debugging symbols take a bit of cheap disk space, they take a bit more
cheap bandwidth to download, and they might possibly cause an extra disk
seek or two as the program loader skips over the executable sections
holding the unused debugging symbols. Big deal here, too.
I understand the argument that by always using the -g version, you can
avoid having complications whereby the exe compiled without debugging
symbols may demonstrate problems the -g does not. However, by again
letting this exception set the rule, you are condemning all software to
run wastefully.
If storage space and CPU time were the only considerations, every
program would still be hand-coded in assembly language.
Ever since computers came down out of the multimillion dollar
stratosphere, human costs have usually swamped storage and computation
costs. So, we have not only debugging symbols in production binaries,
but also very high-level language compilers, managed memory runtimes,
and vast, powerful, and wasteful third-party code libraries. These
things all make programming easier, so programs cost less.
The tradeoff being, we can no longer get a word processor, OS, and the
document being edited to fit into 48 KB.
If you really want to return to those days, they're still selling cheap,
working Apple ][+es on eBay.
Before you make your choice, you might want to listen to an old timer's
recollections that such crude word processors cost about $220 in today's
money. For that, you'd get a product that does less than Microsoft's
Wordpad. (Or Apple's TextEdit, or KDE's KWord, or...) This old-timer
remembers add-on packages costing more than the word
