[2.3 BRANCH]: gstabs issue

[Andrew Hughes]

----- 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.  It's what Oracle intended and still do for the time being.

With DEBUG_BINARIES off before, debug builds produced STABS debug information on x86 and
product/fastdebug builds had no debug information.  When they added separate debuginfo,
they turned it on for product & fastdebug too.  The architecture selection has always
been there.

> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-July/006247.html
> 
> I see that Coleen says:
> 
> > I think we can kill two birds with one stone by just removing
> > DEBUG_BINARIES and using dwarf for linux 32.
> 
> but Daniel Daugherty disagrees.  I don't really understand the size
> argument, given that builds are now done with separate debuginfo.
> Daniel says
> 
> > Getting buy-off on yet another size increase is not a short
> > process.
> 
> but there's no hint about whether he intends to ask for any buy-off.
> 
> I don't even know why DEBUG_BINARIES exists any more: separate
> debuginfo removes the need for it.
> 

It doesn't exist for any technical reason.  It currently exists so Oracle
can have one thing and we can have something else.  Should Oracle choose
to drop STABS on x86, it can be much simplified.

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.

> Andrew.
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07