[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: default -g ??!?

From: Warren Young
Subject: Re: default -g ??!?
Date: Mon, 22 Nov 2010 07:36:01 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20101027 Thunderbird/3.1.6

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]