Re: default -g ??!?

[Warren Young]

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.