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

[Thomas Stüfe]

Hi Volker,

short term, this is okay.

As discussed offlist:

I would prefer a more generic solution for these kind of things, since
we resolve function descriptors at various places already (see struct
FunctionDescriptor) and since ppc64 is also not the only architecture
having function descriptors, this would justify a more generic
solution.

Long term, I would prefer something like

os::resolve_function_address_from_descriptor(address function_descriptor);

with the idea that this is to be called with function names and shall
return the start of the function code. On most archs, this would just
return the input pointer, on ppc64 and other archs like this it would
resolve the function descriptor.

But as I wrote, this change is okay for now.

Suggested change:

- three native pointers where the first pointer is the real function address.
+ three native pointers of which the first pointer is the real function address.

I do not need another webrev.

Thanks, Thomas



On Mon, Jul 2, 2018 at 7:27 PM, Volker Simonis <volker.simonis at gmail.com> 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