RFR(S): 8247516: DSO.closestSymbolToPC() should use dbg.lookup() rather than rely on java ELF file support

Yasumasa Suenaga suenaga at oss.nttdata.com
Tue Aug 4 05:10:12 UTC 2020


Hi Chris,

Looks good.


Yasumasa

On 2020/08/04 13:10, Chris Plummer wrote:
> Ping!
> 
> On 7/27/20 10:04 PM, Chris Plummer wrote:
>> I should have mentioned that currently there is no testing of this code. There will with the changes for [1] JDK-8247514, which will add the lost clhsdb "whatis" functionality, which was lost when JavaScript support went away. "whatis" used DSO.closestSymbolToPC(), so as part of JDK-8247514 I'm adding this support to the PointerFinder class so the "findpc" will also be able to do address to native symbol lookups, and the ClhsdbFindPC will check that it is working.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8247514
>>
>> thanks,
>>
>> Chris
>>
>> On 7/27/20 9:32 PM, Chris Plummer wrote:
>>> Hello,
>>>
>>> Please review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8247516
>>> http://cr.openjdk.java.net/~cjplummer/8247516/webrev.00/index.html
>>>
>>> I put all the details in the description of the CR, including some background on how symbol lookups are done, including what LoadObjects are and their class hierarchy, and also info on JVMDebugger subclasses.
>>>
>>> One thing not covered in the bug description is the additional gutting of DSO.java that comes with these changes. Many APIs were not used so I removed them, such as setBase(), lookupSymbol(), and isDSO(). Doing so allowed completely severing any need for java ELF file support. Note I plan on removing the java ELF file support itself with another CR after pushing these changes.
>>>
>>> thanks,
>>>
>>> Chris
>>
> 


More information about the serviceability-dev mailing list