On 01/08/2010 07:46 PM, Kelly O'Hair wrote:
>
>
> 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.
>
>>
>>> 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... ;^)
I have a nice test for this, of course!
for foo in <find every .so in the tree>
do
eu-strip $foo -f $foo.dbg
done
Then see if jprt and its friends still work.
Andrew.
