JDK-8036003: Add variable not to separate debug information.
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Mon Mar 24 11:33:19 UTC 2014
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
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
So can we agree that for external symbols, there are three ways to deal
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
> Multiple inter-connected choices, not just three (or four if you add
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
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
More information about the build-dev