JDK-8036003: Add variable not to separate debug information. (original) (raw)

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

More information about the core-libs-dev mailing list