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 binaries....given 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 processor itself to
add things like proportional fonts, which we get for free in the RTF
editor that comes bundled with the OS.
For Debian at least, we want unstripped binaries by default. We'll
do the stripping later. There is a reason for this. We provide
"-dbg" packages, which nowadays contain detached debugging symbols.
The dh_strip program handles this as already mentioned.
Well, point taken, and certainly the stuff in my /usr/bin has been
stripped by the distro. Terrific -- but as I said in the other email,
this means you, the distro rep, are potentially setting policies for
source built software (or forcing developers to maintain one for
source downloads, one for debian, one for redhat, etc.)
I think you missed something there. The Debian system gets you a
separate debugging symbols package which you can install on a system to
restore these symbols. That system can't work if you build a .deb from
source that always builds without debugging symbols by default.
Red Hat systems do this, too, by the way. Given foo-1.2.3-1.i386.rpm,
you also have foo-debuginfo-1.2.3-1.i386.rpm, built automagically.
This doesn't help you the first time you hit that blue-moon crash bug,
but at least you can install the debug symbols matching the binary
package, which you have on hand because you keep an archive of all
production RPMs/DEBs, right?
Now when the same thing happens a week later, you have a better chance
of debugging it, and you didn't have to take the customer's system down
again two hours after restarting it so you can reload the debug binaries
you finally got to build for the 8-month-old version they're still
running for some obscure business or support reason. You were able to
avoid that because you just uploaded and installed the debug symbols
while you had the customer on the phone, and restarted the system with
them in place.
It's almost a form of imperialism, if you get my drift ;) How does it
fit in with the GNU philosophy of user empowerment vs. "proprietary"
policy making?
You have to pick a default. GNU chose the one that gives the most
choices down the road.
One of the choices that default buys you is the ability to build
stripped binaries or to strip them yourself if you want, later.
The alternative doesn't afford that choice: you can't unstrip a program.
Okay, so to stretch the analogy: one imperialist nation follows the
example of another, so this justifies it? Methinks "the emperor wears
no clothes" here.
Bad car analogies, check.
Bombastic political rhetoric in a heretofore apolitical thread, check.
Next up, a dictionary flame, followed by validation of Godwin's Law.