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

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