On 2014-03-21 09:57, David Holmes wrote:
And while, technically, you can save symbols externally, and at the same
time keep them in the binary, that does not make sense. So, in a
practical sense, you are going to do #2 if you are going to do #3.
But you can vary what is kept internally independent of what is made
external.
While that technically is correct, not all combinations does make sense.
And you can't zip external symbols unless you create a non-zipped
version. And if you zip them, it does not make sense to keep the
non-zipped version.
zip vs non-zip is just an issue of disk space. It is not a fundamental
configuration choice, just a variation on how external symbols are
packaged.
So can we agree that for external symbols, there are three ways to deal
with them:
no external symbols
unzipped external symbols
zipped external symbols
?
Can you give a more concrete example of the variations of your "aspects"
that you think my suggested solution would not capture?
I think I already have. There aren't tree simple choices here, there
are three aspects, each of which could have different variants.
If I could draw a flow chart easily I would but basically if you
generate debug symbols you can then select what symbols are kept
internally (the strip policy) and what are put externally (objcopy
options), then for the external symbol file you can choose zipped or
unzipped.
Multiple inter-connected choices, not just three (or four if you add
zipped)
And then there's the aspect that got this bug started, that you need to
compile with -g to be able to have any useful symbols at all.
While technically you can compile without -g and then run strip, it's a
combination that does not make sense.
In the end, it all boils down to a few sensible ways to handle all debug
information.
1) The Oracle way -- copying debug information into an external format
(that by default is zipped), and stripping the binary as much as reasonable.
2) The community way -- keep everything in the binary, and not creating
a separate external format.
3) The hardcore way -- ignore debug information alltogether.
Instead of providing a lots of handles and knobs to configure, that will
allow the user to configure invalid (e.g. zip-external=true,
produce-external=false), or meaningless (compile-with-debug-flag=yes,
strip=everything, produce-external=false), I'd rather provide a
high-level option (or two, if it's not possible to condense into a
single option) that allows the user to express the intent. And for all
practical purposes, it's going to be set to either "oracle mode" or
"community mode".
/Magnus
