Build-infra mismatch with full debug symbol control for hotspot

[Kelly O'Hair]

Thanks for filing this.

When you get a chance, I would like to get an understanding of what the schedule is for integrating the
profiles repositories into jdk8/jdk8, and if they will go through jdk8/build or some other path.

-kto

On Oct 28, 2012, at 5:12 PM, David Holmes wrote:

> I've filed a bug for this:
> 
> https://jbs.oracle.com/bugs/browse/JDK-8001753
> 
> I'll have to put in a quick fix for the profile builds, but I think the new build should have followed the existing nomenclature (or else, if someone felt so strongly that the nomenclature was "wrong", modified the old build for the JDK and Hotspot). There needs to be consistent naming though.
> 
> David
> 
> On 27/10/2012 1:58 PM, Daniel D. Daugherty wrote:
>> I would think that the the new build system would use the same
>> internal make variable name as the old build system, i.e.,
>> 
>> ENABLE_FULL_DEBUG_SYMBOLS
>> 
>> I would also expect the variable to use the same values ('1' and '0').
>> However, I'm not up to speed on build-infra...
>> 
>> Dan
>> 
>> 
>> On 10/26/12 9:54 PM, David Holmes wrote:
>>> I may be mis-reading something here but was trying to determine why
>>> hotspot was still creating debuginfo/diz files when I thought I had
>>> disabled it at configure time.
>>> 
>>> In the old build the external variable that should be set to control
>>> FDS is FULL_DEBUG_SYMBOLS. This is turn will set the internal make
>>> variable ENABLE_FULL_DEBUG_SYMBOLS. This applies to JDK builds and
>>> hotspot builds, with the top-level build adding FULL_DEBUG_SYMBOLS to
>>> the HOTSPOT_BUILD_ARGUMENTS.
>>> 
>>> But in the new build the variable that is modified based on
>>> --disable-debug-symbols is ENABLE_DEBUG_SYMBOLS. And it gets set to
>>> yes or no, not 1 or 0. So hotspot will read spec.gmk and only find
>>> ENABLE_DEBUG_SYMBOLS:=no, for example, but that has no affect on FDS
>>> as it expects FULL_DEBUG_SYMBOLS to control things.
>>> 
>>> What is the best way to resolve this mismatch?
>>> 
>>> I've cc'd Dan as the FDS expert.
>>> 
>>> Thanks,
>>> David