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

[Kelly O'Hair]

Andrew John Hughes wrote:
> 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/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-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? :)

I've pinged Dan on this. We will ask MarkR to purge these hotspot-svc
repositories.

> 
>>>> 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.
>>

Both JPRT jobs came back fine.

-kto

>> Testing this particular functionality is another story of course, never
>> easy to test features that require something to go wrong... ;^)
>>
>> -kto
>>
>>>
>>>> -kto
>>>>
>>>>> Thanks.
>>>>> Andrew.
>>>
>>>
> 
> 
>