Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files (original) (raw)

Andrew John Hughes gnu_andrew at member.fsf.org
Fri Jan 8 20:03:35 UTC 2010

2010/1/8 Kelly O'Hair <Kelly.Ohair at sun.com>:

Andrew John Hughes wrote:

2010/1/8 Kelly O'Hair <Kelly.Ohair at sun.com>:

Andrew Haley wrote:

On 12/09/2009 03:36 PM, Andrew Haley wrote:

This is https://bugzilla.redhat.com/showbug.cgi?id=541548 The symptom is that jmap doesn't work because target libraries are stripped. The fix is to allow the symtab reader to use the separate debuginfo files that are available for all (AFAIK) GNU/Linux distributions. This is now also https://bugs.openjdk.java.net/showbug.cgi?id=100126 Webrev at http://cr.openjdk.java.net/~aph/100126-hotspot-webrev/ I have now checked several Linux distros, old and new, and although they keep their debuginfo files in different places, this patch works on all of them. Is this OK?  And, if so, which repos should I push the patch to? I'm a little concerned about the impact this might have on hotspot as it will eventually get delivered into a jdk6 release (I assume). And jdk6 does builds on really old Linux systems, e.g. "Red Hat Enterprise Advanced Server 2.1 update 2". Can you think of anything that might be a problem with that? Either at compile time or runtime? aph will be able to respond to this in more detail, but my understanding of the patch is that it only tries separate debug files if it doesn't find debuginfo in the binary itself.  If the builds om RHEL AS 2.1 use non-stripped binaries, it won't even get that far AFAICS.  And if they don't and /usr/lib/debug also doesn't exist, then it will just fail as it always did. So the only issue would be that the code relies on building against something newer than it did previously. I still am a bit uncomfortable with that 1K block of bytes we are adding, but I'll resign from that debate, if this is the official way to do it. How many of these 1K blocks are floating around the system? :^( The change probably needs to go through one of the hotspot forests, maybe hotspot-rt? I would have assumed hotspot-svc as it's serviceability-related. The hotspot-svc forest has been abandoned in favor of hotspot-rt, or hotspot-rt has consumed it, depends on your point of view. Strange, I remember an email on this back in Nov 2008, but it appears to never have been sent out to the serviceability-dev at openjdk.java.net alias. The primary issue was resources in doing testing and integration of a 4th developer forest, the 3 (gc, comp, rt) seemed to be consuming all our testing resources.

Ah ok, that makes sense with the separate serviceability tree going too. I only checked hg.openjdk.java.net. Maybe it's time to nuke some of these dead trees? :)

In the meantime, I will take this patch and apply it, and make sure hotspot still builds with the jdk6 and jdk7 Linux systems we have.

Thanks.  HotSpot patches go through JPRT so that should also give it some build testing. I fired off two JPRT jobs, one for jdk6 and one for jdk7, with this patch applied. Builds and testing. I'll let you know what I find out. Testing this particular functionality is another story of course, never easy to test features that require something to go wrong... ;^) -kto

-kto Thanks. Andrew.

-- Andrew :-)

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

Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

More information about the core-libs-dev mailing list