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 
> 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 
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".


More information about the hotspot-dev mailing list