[2.3 BRANCH]: gstabs issue

[Andrew Haley]

On 08/06/2012 07:09 PM, Andrew Hughes wrote:
> ----- Original Message -----
>> On 08/06/2012 05:16 PM, Andrew Hughes wrote:
>>> ----- Original Message -----
>>>> On 08/06/2012 02:42 PM, Andrew Hughes wrote:
>>>>> There was a regression with DEBUG_BINARIES which resulted in some
>>>>> architectures
>>>>> (x86, SPARC, etc.) producing STABS debug information rather than
>>>>> DWARF.
>>>>>
>>>>> The fix for this is now in OpenJDK8 and IcedTea7 HEAD:
>>>>>
>>>>> http://hg.openjdk.java.net/icedtea/jdk7/hotspot/rev/c5430c659d54
>>>>>
>>>>> Ok to backport this to the 2.3 forest?
>>>>
>>>> It's very hard to understand what is supposed to be happening.  I
>>>> think it means that ia64, amd64, arm, ppc get DWARF debug info,
>>>> but
>>>> x86/32 and others get STABS.  But this makes no sense at all:
>>>> STABS
>>>> is not appropriate for x86/32 or any other Linux target AFAIAA.
>>>
>>> No, that's what's happening now without this patch.  This patch
>>> corrects the behaviour so that DEBUG_BINARIES again takes
>>> precedence
>>> and applies "-g" in all cases (no "-gstabs") whatever the
>>> architecture or build type (fastdebug/debug/product).  It's hard to
>>> see because the patch is moving the previous lines inside an else
>>> block, which is only evaluated if DEBUG_BINARIES is not equal to
>>> true.
>>
>> OK, so it's still wrong if DEBUG_BINARIES is off, but it's only wrong
>> on hosts other than ia64, amd64, arm and ppc.
> 
> "Wrong" for us yes.  

Well, it results in a grossly degraded debug experience for everyone.
I suspect that internally the HotSpot team do almost all of their
debugging in debug builds anyway.

> It's what Oracle intended and still do for the time being.

> But we need what is a regression for us fixed ASAP, hence this interim patch,
> rather than waiting for Oracle to make their minds up, especially if they
> decide to stick with STABS for whatever reason.

OK, true enough, but we need to make sure that this never affects us
again.

Andrew.