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

Kelly O'Hair Kelly.Ohair at Sun.COM
Fri Jan 8 23:10:50 UTC 2010

Andrew John Hughes wrote:
> 2010/1/8 Kelly O'Hair <Kelly.Ohair at>:
>> Andrew John Hughes wrote:
>>> 2010/1/8 Kelly O'Hair <Kelly.Ohair at>:
>>>> Andrew Haley wrote:
>>>>> On 12/09/2009 03:36 PM, Andrew Haley wrote:
>>>>>> This is
>>>>>> 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
>>>>> Webrev at
>>>>> 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
>> 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  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

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


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

More information about the core-libs-dev mailing list