2010/1/8 Kelly O'Hair <kelly.oh...@sun.com>: > > > Andrew John Hughes wrote: >> >> 2010/1/8 Kelly O'Hair <kelly.oh...@sun.com>: >>> >>> Andrew Haley wrote: >>>> >>>> On 12/09/2009 03:36 PM, Andrew Haley wrote: >>>>> >>>>> This is https://bugzilla.redhat.com/show_bug.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/show_bug.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-...@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
