RFR(XS): MallocSiteTable::initialize() doesn't take function descriptors into account
zgu at redhat.com
Tue Jul 3 11:47:15 UTC 2018
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 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 = (address)MallocSiteTable::allocation_at;
>> pc = (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.
>> On 07/02/2018 01:27 PM, Volker Simonis wrote:
>>> can I please have a review for this trivial change which fixes a
>>> problem on Linux/ppc64
>>> 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
>>> 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,
More information about the hotspot-dev