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

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Fri Mar 21 08:14:28 UTC 2014

> I don't think this quite works as there are other variations not 
> captured here. Rather than "zipped" it should just be "external". 
> Whether the debuginfo files are zipped or not is then an additional 
> build time option. Additionally we still have to be able to control 
> the degree of stripping that is carried out. It doesn't make sense to 
> me to try and enumerate all possible combinations as top-level 
> configure options.
> Further, as Dan was saying, this doesn't capture the overlap between 
> "internal" and "external" because we still leave some symbols internal 
> even when creating the debuginfo file.
> So I don't think this proposed categorization works. We still have 
> three aspects:
> - generating symbols into the object files
> - stripping symbols from the final binaries
> - saving symbols into an external form
> Each of which can potentally be varied (of course if you don't 
> generate symbols in the obj files stripping and saving are non issues).

But they are not independent on each other!

Unless you generate debug symbols, you can't strip them, nor save them 
elsewhere. So generating debug symbols (your item #1) is a prerequisite 
for the rest of your items.

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.

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.

And yes, we do not strip all debug information when creating external 
debug info. But there seems to be no real use case (not even for 
IcedTea, as it turned out) to want a completely stripped binary, I don't 
think that's worth discussing much. That's just part of how the external 
debuginfo scheme works.

Can you give a more concrete example of the variations of your "aspects" 
that you think my suggested solution would not capture?


More information about the core-libs-dev mailing list