RFR [S]: 8079473: allow demangling to be optional in dll_address_to_function_name (original) (raw)

Thomas Stüfe thomas.stuefe at gmail.com
Wed Oct 7 15:22:42 UTC 2015

Hi Bertrand, Volker,

it may even make sense to disable demangling on AIX by default. AIX Demangle() function is shaky, so we did switch it off in our VM.

Kind Regards, Thomas

On Fri, Jun 12, 2015 at 12:01 PM, Bertrand Delsart < bertrand.delsart at oracle.com> wrote:

Thanks Volker,

Bertrand.

On 12/06/2015 11:48, Volker Simonis wrote: 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 dlladdresstofunctionname 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)) { jiosnprintf(buf, buflen, "%s", pSymbol->Name); } The code is supposed to write in 'buf' the raw form when the demangling fails. Hence, the jiosnprintf 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 (!(demanglename && 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 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