JDK-8036003: Add variable not to separate debug information.

[Magnus Ihse Bursie]

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