JDK-8036003: Add variable not to separate debug information.
david.holmes at oracle.com
Thu Mar 20 12:24:41 UTC 2014
On 18/03/2014 6:59 PM, Magnus Ihse Bursie wrote:
> On 2014-03-18 02:19, Andrew Hughes wrote:
>> Do we need more than just the following three alternatives?
>> #1. No debugging information at all.
>> #2. Debugging information left in the original binaries.
>> #3. Debugging information stripped from the binaries and zipped in
>> separate files.
>> It sounds to me like Oracle want #3, while distros want #2 and I
>> imagine some
>> end users may just want #1 for a faster, smaller build.
> I'm completely thinking along your lines here. I think we should focus
> on the end result, not the specific implementations details. I've been
> thinking about exposing a configure option like this:
> --with-debug-symbols=none (for #1)
> --with-debug-symbols=internal (for #2)
> --with-debug-symbols=zipped (for #3)
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
- 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 perhaps with better names. I also imagine there might be a use case
> for yet another option,
> #4. Debuggin information stripped from the binaries, but not zipped
> expressed like this
> And then this would be the only user interface needed, and the rest of
> the current set of not-really-clear flags can be hidden inside the
> configure script.
> For compatibility reasons, the default would be
> --with-debug-symbols=zipped (which is called "FDS" here), just as we
> currently do, but distributions would just need to add a
> --with-debug-symbols=internal to get what they want.
More information about the core-libs-dev