RFR: [XS]: 8236183: cleanup Java_jdk_internal_reflect_Reflection_getCallerClass naming - was : RE: running java with LD_DEBUG-tracing
david.holmes at oracle.com
Wed Dec 18 22:02:30 UTC 2019
Looks good. Thanks for fixing and finding. :)
On 19/12/2019 12:33 am, Baesken, Matthias wrote:
> Hello David,
> Here is a change that adjusts the naming of Java_jdk_internal_reflect_Reflection_getCallerClass -
> With this change, I checked the output of LD_DEBUG=libs java Test , and the error I observed before is gone .
> Bug/webrev :
> Thanks, Matthias
>>>> By chance I noticed the following output when running a trivial Java
>>>> program :
>>>> LD_DEBUG=libs /linuxx86_64/output-jdk-
>> test/images/jdk/bin/java Test
>>>> . . .
>>>> /linuxx86_64/output-jdk-test/images/jdk/lib/libjava.so: error: symbol
>>>> lookup error: undefined symbol:
>>>> Java_jdk_internal_reflect_Reflection_getCallerClass (fatal)
>>>> What is wrong with
>>>> "Java_jdk_internal_reflect_Reflection_getCallerClass" ?
>>>> Does the error message occur because of the naming
>>>> Java_jdk_internal_reflect_Reflection_getCallerClass__ with the added
>>>> "__" at the end of the method (Reflection.c) ?
>>> That definitely looks like an error in the C source to me. The ending
>>> "__" should not be there. How is this working ??
>> Ah! It is a remnant of when there were overloads of getCallerClass. The
>> "__" should be followed by the signature - which is empty in this case.
>> So IIRC the lookup will first try to use the short name (without the
>> trailing "__") which will fail, then it will use the long name which
>> will succeed.
>> It should be fixed so we don't waste time doing two lookups.
More information about the core-libs-dev