fastdebug builds broken for jdk9/hs tree?

[David Holmes]

On 29/04/2016 5:39 PM, Severin Gehwolf wrote:
> On Fri, 2016-04-29 at 17:28 +1000, David Holmes wrote:
>> Hi Severin,
>>
>> On 29/04/2016 2:35 AM, Severin Gehwolf wrote:
>>>
>>> Hi,
>>>
>>> Recently, a fastdebug build of a server JVM fails for me on Linux
>>> x86_64 with older sys/sdt.h and/or GCC. The same failure shows up since
>>> a couple of days on the Zero builder[1]:
>>>
>>> /home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp: In static member function ‘static void ClassLoadingService::notify_class_loaded(InstanceKlass*, bool)’:
>>> /home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp:148: error: cannot reload integer constant operand in ‘asm’
>>> /home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp:148: error: cannot reload integer constant operand in ‘asm’
>>> gmake[4]: *** [/home/sgehwolf/openjdk9-hs-pristine/build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/libjvm/objs/classLoadingService.o] Error 1
>>> gmake[4]: Leaving directory `/home/sgehwolf/openjdk9-hs-pristine/hotspot/make'
>>>
>>> On that line is a macro for dtrace:
>>>
>>> void ClassLoadingService::notify_class_loaded(InstanceKlass* k, bool shared_class) {
>>>   DTRACE_CLASSLOAD_PROBE(loaded, k, shared_class); // <<< This fails
>>>
>>> If I compile the same file *without* -DDTRACE_ENABLE it compiles fine.
>>> A slowdebug build compiles fine too. I was able to *reproduce* this on
>>> RHEL 6. It *does not* reproduce on F23.
>>>
>>> I had a brief look at the preprocessed compilation unit for
>>> classLoadingService and the code that gets included for the dtrace
>>> macro looks different.
>>>
>>> So here the questions:
>>>
>>> 1.) Has anything related to dtrace macros changed recently?
>>> 2.) Has anybody else been seeing this?
>> This would seem to be an issue with the content of sdt.h and the version
>> of gcc being used. Have either of those changed at your end? This seems
>> external to the OpenJDK sources ... though perhaps there is a build
>> related issue? How recently did this start - did it happen after the
>> switch to the new hotspot build?
>
> It might be. I'll investigate. I'm not aware of any gcc/systemtap
> changes, but I'll have a closer look.
>
> I take it that's a no to question 1 above?

Nothing on our side, and there is no asm in anything in our sources 
AFAICS so I assume it is something in sdt.h. Only change here was a few 
weeks back for jigsaw:

  > hg log -p ./os/posix/dtrace/hotspot_jni.d
changeset:   10487:c558850fac57
tag:         jdk-9+111
parent:      10484:0de4d895a5c8
user:        alanb
date:        Thu Mar 17 19:04:01 2016 +0000
summary:     8142968: Module System implementation

diff -r 0de4d895a5c8 -r c558850fac57 src/os/posix/dtrace/hotspot_jni.d
--- a/src/os/posix/dtrace/hotspot_jni.d
+++ b/src/os/posix/dtrace/hotspot_jni.d
@@ -300,6 +300,8 @@
    probe GetLongField__return(uintptr_t);
    probe GetMethodID__entry(void*, void*, const char*, const char*);
    probe GetMethodID__return(uintptr_t);
+  probe GetModule__entry(void*, void*);
+  probe GetModule__return(void*);
    probe GetObjectArrayElement__entry(void*, void*, uintptr_t);
    probe GetObjectArrayElement__return(void*);

David

> Cheers,
> Severin
>
>> Cheers,
>> David
>> -----
>>
>>>
>>> Thanks,
>>> Severin
>>>
>>> [1] http://builder.classpath.org/jenkins/job/OpenJDK9_hs_rt_Zero/227/console
>>>
>