RFR(L): 8037816 : Fix for 8036122 breaks build with Xcode5/clang
david.r.chase at oracle.com
Tue Apr 29 02:56:12 UTC 2014
On 2014-04-28, at 6:12 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> The same as John said:
> Use print_raw(msg) for now and file RFE to rename (I prefer puts()).
> Use cr() for empty strings.
Done, except for the pending RFE.
> os_linux.cpp: you can include space into format now after you added "%s"
> - st->print("%s", os::Linux::glibc_version()); st->print(" ");
> + st->print("%s ", os::Linux::glibc_version());
> Do the same in your changes in os_posix.cpp instead of using print_raw().
> I don't like "0x%" PRIxPTR combination. Can you use PTR_FORMAT instead of "0x%" PRIxPTR ?:
> + case T_OBJECT: out->print("obj:0x%" PRIxPTR, p2i(as_jobject())); break;
> + case T_METADATA: out->print("metadata:0x%" PRIxPTR, p2i(as_metadata()));break;
Done. Note that this will change the output -- PTR_FORMAT is 8 or 16 hex digits, always.
> and INTPRT_FORMAT for:
> out->print("%3d:0x" UINT64_FORMAT_X, type(), (uint64_t)as_jlong());
This gets messy, because the only reliable name I have for a 64-bit type and format is [u]int64.
Pointers can be 32-bits wide on some platforms. (So no, I actually can't make this work.)
> The places with absent '0x' should be fixed IMHO. For example in c1_Runtime1.cpp: 'at pc %" PRIxPTR,'
Done. Replaced with PTR_FORMAT, which includes the 0x (and 8 or 16 hex digits always).
> Can you fix vm_version_<arc>.cpp by casting flags values to (int)?
I would prefer not to -- this could have wider effects than the format fixes I have made, and that would require a lot of testing with a lot of different flag values to be sure I didn't screw something else up unintentionally.
> arguments.cpp: Can you use (uint) instead of (unsigned int)?
All instances of "Done" passed preliminary testing, and I'll redo all the other testing tomorrow.
More information about the hotspot-dev