RFR [S]: 8079473: allow demangling to be optional in dll_address_to_function_name

Volker Simonis volker.simonis at gmail.com
Fri Jun 12 09:48:52 UTC 2015


Hi Bertrand,

thanks for caring about the AIX port.
The AIX changes look good and work perfectly.

Regards,
Volker


On Fri, Jun 12, 2015 at 8:28 AM, Bertrand Delsart
<bertrand.delsart at oracle.com> wrote:
> Thanks David,
>
> Reminder: this webrev includes trivial but untested AIX changes. Second
> reviewer need not be from the AIX porting team but feedback appreciated.
>
> Regards,
>
> Bertrand.
>
>
> On 12/06/2015 05:53, David Holmes wrote:
>>
>> Hi Bertrand,
>>
>> This all looks okay to me. Thanks for the detailed description.
>>
>> Thanks,
>> David
>>
>> On 28/05/2015 11:52 PM, Bertrand Delsart wrote:
>>>
>>> Hi all,
>>>
>>> Here is a webrev that add a 'demangle' argument to
>>> dll_address_to_function_name so as to make the demangling optional. The
>>> webrev also includes some limited cleanup and fixes an issue I noticed
>>> on windows.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8079473
>>> http://cr.openjdk.java.net/~bdelsart/8079473/
>>>
>>> Fix is targeted at JDK9 and will be pushed through hs-rt.
>>>
>>> This enhancement is currently used only by some closed extensions. It
>>> has been validated on linux and the fix is very similar on all platforms
>>> except AIX.
>>>
>>> I've quickly implemented the AIX version but could not test it. Let me
>>> know if you would prefer me to remove the AIX code and just ensure that
>>> the 'demangle' argument is ignored on that platform.
>>>
>>> The cleanup is about optional arguments to decode, which were redefined
>>> in the overridden versions for the different operating systems. To avoid
>>> weird behaviors, the default values should be defined only in the
>>> toplevel class AbstractDecoder, not the subclasses (but that was OK as
>>> long as the default values were identical)
>>>
>>> On Windows, I discovered a bug while adding the non-demangling support.
>>> This old code from WindowsDecoder::decode should not behave as expected
>>> if really used:
>>>          if (demangle(pSymbol->Name, buf, buflen)) {
>>>            jio_snprintf(buf, buflen, "%s", pSymbol->Name);
>>>          }
>>> The code is supposed to write in 'buf' the raw form when the demangling
>>> fails. Hence, the jio_snprintf should be executed when demangle returns
>>> false. The code above fails to properly set buf when the demangling
>>> fails and also replaced the demangled form by the raw form when
>>> demangling succeeded.
>>>
>>> It should have been "if (! demangle(...". With my extension, it now is
>>> "if (!(demangle_name && demangle(...", like on other platforms.
>>>
>>> Best regards,
>>>
>>> Bertrand.
>
>
>
> --
> Bertrand Delsart,                     Grenoble Engineering Center
> Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
> 38330 Montbonnot Saint Martin,                             FRANCE
> bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> please contact the sender by reply email and destroy all copies of
> the original message.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


More information about the hotspot-runtime-dev mailing list