[11] RFR(XS): MallocSiteTable::initialize() doesn't take function descriptors into account

Zhengyu Gu zgu at redhat.com
Tue Jul 3 12:38:18 UTC 2018


BTW, patch looks good as short term fix.

Thanks,

-Zhengyu

On 07/03/2018 07:47 AM, Zhengyu Gu wrote:
> 
> 
> On 07/03/2018 03:03 AM, Volker Simonis wrote:
>> On Tue, Jul 3, 2018 at 1:09 AM, Zhengyu Gu <zgu at redhat.com> wrote:
>>> Hi Volker,
>>>
>>> fp[0] should work with little endian as well, right?
>>>
>>
>> Yes, of course. But little endian doesn't use function descriptors. On
>> little endian the new ABI ELFv2 version is used which uses plain
>> function pointers like on x86.
> 
> Ah, thanks for explaining.
> 
>>
>>> I wonder if change
>>>
>>> pc[2] = (address)MallocSiteTable::allocation_at;
>>>
>>> to
>>>
>>> pc[2] = (address)(&MallocSiteTable::allocation_at);
>>>
>>> will work.
>>>
>>
>> No it won't! You really have to manually decompose the function
>> descriptor. You also have to be careful when trying things in gdb
>> because inside gdb you may manage to cast the function descriptor to
>> the corresponding function pointer. But the C/C++ compiler only gives
>> you access to the function descriptor.
> 
> 
> I agree with Thomas, ABI issues should be addressed at os level. The 
> comments in elfFuncDescTable.hpp mentions "and other architectures like 
> for example IA64 ...", not sure if "other" will pop up at some point.
> 
> Thanks,
> 
> -Zhengyu
> 
> 
>>
>> Regards,
>> Volker
>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>> On 07/02/2018 01:27 PM, Volker Simonis wrote:
>>>>
>>>> Hi,
>>>>
>>>> can I please have a review for this trivial change which fixes a
>>>> problem on Linux/ppc64
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8206173/
>>>> https://bugs.openjdk.java.net/browse/JDK-8206173
>>>>
>>>> MallocSiteTable::initialize() creates a pseudo call stack for
>>>> hashtable entry allocations which is populated with the addresses of
>>>> some well-known static methods.
>>>>
>>>> However, taking the address of a function or static method in C/C++
>>>> isn't required to return the actual code address where that function
>>>> lives in memory. On ppc64 (i.e. big-endian, ABI ELFv1) applying the
>>>> address operator on a function will return the functions "function
>>>> descriptor" (see
>>>>
>>>> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#FUNC-DES) 
>>>>
>>>> which is a struct of three pointers where the first one points to the
>>>> actual function address.
>>>>
>>>> In order to get a correct stack trace on ppc64 as well, we therefore
>>>> have to dereference the function descriptor before we can store the
>>>> real function address in the stack trace.
>>>>
>>>> In order to make the shared code fix less intrusive, I've added a pair
>>>> of LITTLE_ENDIAN_ONLY/BIG_ENDIAN_ONLY macros to macros.hpp.
>>>>
>>>> This bug is the reason why runtime/ElfDecoder/TestElfDirectRead.java
>>>> fails on Linux/ppc64.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>


More information about the hotspot-dev mailing list