* [RFA] Add JDWP VM_INIT JVMTI callback @ 2007-01-16 6:40 Keith Seitz 2007-01-16 19:38 ` Tom Tromey 2007-01-19 0:00 ` Marco Trudel 0 siblings, 2 replies; 18+ messages in thread From: Keith Seitz @ 2007-01-16 6:40 UTC (permalink / raw) To: Java Patch List [-- Attachment #1: Type: text/plain, Size: 571 bytes --] Hi, This patch adds a JVMTI VM_INIT callback to be used by the JDWP code. Currently this function simply sends the JDWP VM_INIT event notification, but later it will do install additional JVMTI callbacks for all the various JDWP event notifications. Comments/questions/concerns? Keith ChangeLog 2007-01-15 Keith Seitz <keiths@redhat.com> * gnu/classpath/jdwp/natVMVirtualMachine.cc (DEFINE_CALLBACK): New macro. (ENABLE_EVENT): New macro. (initialize): Define and enable JVMTI VM_INIT callback. (jdwpVMInitCB): New function. [-- Attachment #2: vminitcb.patch --] [-- Type: text/x-patch, Size: 2008 bytes --] Index: gnu/classpath/jdwp/natVMVirtualMachine.cc =================================================================== --- gnu/classpath/jdwp/natVMVirtualMachine.cc (revision 120805) +++ gnu/classpath/jdwp/natVMVirtualMachine.cc (working copy) @@ -24,10 +24,12 @@ #include <java/util/Hashtable.h> #include <java/util/Iterator.h> +#include <gnu/classpath/jdwp/Jdwp.h> #include <gnu/classpath/jdwp/VMFrame.h> #include <gnu/classpath/jdwp/VMMethod.h> #include <gnu/classpath/jdwp/VMVirtualMachine.h> #include <gnu/classpath/jdwp/event/EventRequest.h> +#include <gnu/classpath/jdwp/event/VmInitEvent.h> #include <gnu/classpath/jdwp/exception/JdwpInternalErrorException.h> #include <gnu/classpath/jdwp/util/MethodResult.h> @@ -35,6 +37,13 @@ using namespace gnu::classpath::jdwp::event; using namespace gnu::classpath::jdwp::util; +// Forward declarations +static void jdwpVMInitCB (jvmtiEnv *env, JNIEnv *jni_env, jthread thread); + +#define DEFINE_CALLBACK(Cb,Event) Cb.Event = jdwp ## Event ## CB +#define ENABLE_EVENT(Event,Thread) \ + _jdwp_jvmtiEnv->SetEventNotificationMode (JVMTI_ENABLE, \ + JVMTI_EVENT_ ## Event, Thread) // JVMTI environment static jvmtiEnv *_jdwp_jvmtiEnv; @@ -44,6 +53,12 @@ _jdwp_suspend_counts = new ::java::util::Hashtable (); JavaVM *vm = _Jv_GetJavaVM (); vm->GetEnv (reinterpret_cast<void **> (&_jdwp_jvmtiEnv), JVMTI_VERSION_1_0); + + // Wait for VM_INIT to do more initialization + jvmtiEventCallbacks callbacks; + DEFINE_CALLBACK (callbacks, VMInit); + _jdwp_jvmtiEnv->SetEventCallbacks (&callbacks, sizeof (callbacks)); + ENABLE_EVENT (VM_INIT, NULL); } void @@ -343,3 +358,13 @@ { return NULL; } + +static void +jdwpVMInitCB (MAYBE_UNUSED jvmtiEnv *env, MAYBE_UNUSED JNIEnv *jni_env, + jthread thread) +{ + // Send JDWP VMInit + using namespace gnu::classpath::jdwp::event; + Thread *init_thread = reinterpret_cast<Thread *> (thread); + gnu::classpath::jdwp::Jdwp::notify (new VmInitEvent (init_thread)); +} ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-16 6:40 [RFA] Add JDWP VM_INIT JVMTI callback Keith Seitz @ 2007-01-16 19:38 ` Tom Tromey 2007-01-16 19:54 ` Keith Seitz 2007-01-19 0:00 ` Marco Trudel 1 sibling, 1 reply; 18+ messages in thread From: Tom Tromey @ 2007-01-16 19:38 UTC (permalink / raw) To: Keith Seitz; +Cc: Java Patch List >>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes: Keith> This patch adds a JVMTI VM_INIT callback to be used by the JDWP Keith> code. Currently this function simply sends the JDWP VM_INIT event Keith> notification, but later it will do install additional JVMTI callbacks Keith> for all the various JDWP event notifications. Keith> Comments/questions/concerns? Ok, thanks. Tom ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-16 19:38 ` Tom Tromey @ 2007-01-16 19:54 ` Keith Seitz 0 siblings, 0 replies; 18+ messages in thread From: Keith Seitz @ 2007-01-16 19:54 UTC (permalink / raw) To: Java Patch List Tom Tromey wrote: > Ok, thanks. Done. Thank you for taking a look. Keith ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-16 6:40 [RFA] Add JDWP VM_INIT JVMTI callback Keith Seitz 2007-01-16 19:38 ` Tom Tromey @ 2007-01-19 0:00 ` Marco Trudel 2007-01-19 0:03 ` Keith Seitz 2007-01-19 0:05 ` Andrew Haley 1 sibling, 2 replies; 18+ messages in thread From: Marco Trudel @ 2007-01-19 0:00 UTC (permalink / raw) To: Keith Seitz; +Cc: Java Patch List [-- Attachment #1: Type: text/plain, Size: 8922 bytes --] Keith Seitz wrote: > Hi, > > This patch adds a JVMTI VM_INIT callback to be used by the JDWP code. > Currently this function simply sends the JDWP VM_INIT event > notification, but later it will do install additional JVMTI callbacks > for all the various JDWP event notifications. > > Comments/questions/concerns? This breaks at least cross-compilation for host=Linux target=minGW: /home/Marco/Desktop/compile-lin-win/gcc-build/./gcc/xgcc -shared-libgcc -B/home/Marco/Desktop/compile-lin-win/gcc-build/./gcc -nostdinc++ -L/home/Marco/Desktop/compile-lin-win/gcc-build/i686-pc-mingw32/libstdc++-v3/src -L/home/Marco/Desktop/compile-lin-win/gcc-build/i686-pc-mingw32/libstdc++-v3/src/.libs -L/home/Marco/Desktop/compile-lin-win/gcc-build/i686-pc-mingw32/winsup/mingw -L/home/Marco/Desktop/compile-lin-win/gcc-build/i686-pc-mingw32/winsup/w32api/lib -isystem /usr/local/src/gcc/winsup/mingw/include -isystem /usr/local/src/gcc/winsup/w32api/include -B/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/i686-pc-mingw32/bin/ -B/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/i686-pc-mingw32/lib/ -isystem /home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/i686-pc-mingw32/include -isystem /home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/i686-pc-mingw32/sys-include -DHAVE_CONFIG_H -I. -I/usr/local/src/gcc/libjava -I./include -I./gcj -I/usr/local/src/gcc/libjava -Iinclude -I/usr/local/src/gcc/libjava/include -I/usr/local/src/gcc/libjava/classpath/include -Iclasspath/include -I/usr/local/src/gcc/libjava/classpath/native/fdlibm -I/usr/local/src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include -I/usr/local/src/gcc/libjava/libltdl -I/usr/local/src/gcc/libjava/libltdl -I/usr/local/src/gcc/libjava/.././libjava/../gcc -I/usr/local/src/gcc/libjava/../zlib -I/usr/local/src/gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -mthreads -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -fno-omit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win\" -DTOOLEXECLIBDIR=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/i686-pc-mingw32/lib\" -DJAVA_HOME=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win\" -DBOOT_CLASS_PATH=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/share/java/libgcj-4.3.0.jar\" -DJAVA_EXT_DIRS=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/lib/gcj-4.3.0\" -DPATH_SEPARATOR=\":\" -DLIBGCJ_DEFAULT_DATABASE=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/lib/gcj-4.3.0/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.3.0/classmap.db\" -g -O2 --sysroot=/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/sys-root -MT gnu/classpath/jdwp/natVMVirtualMachine.lo -MD -MP -MF gnu/classpath/jdwp/.deps/natVMVirtualMachine.Tpo -c /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc -o gnu/classpath/jdwp/natVMVirtualMachine.o /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc: In static member function 'static void gnu::classpath::jdwp::VMVirtualMachine::initialize()': /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:55: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:59: error: invalid conversion from 'void (*)(jvmtiEnv*, JNIEnv*, java::lang::Object*)' to 'void (*)(jvmtiEnv*, JNIEnv*, java::lang::Object*)' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc: At global scope: /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:278: warning: unused parameter 'kind' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:295: warning: unused parameter 'klass' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:301: warning: unused parameter 'klass' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:307: warning: unused parameter 'klass' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:307: warning: unused parameter 'id' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:315: warning: unused parameter 'thread' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:315: warning: unused parameter 'start' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:315: warning: unused parameter 'length' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:322: warning: unused parameter 'thread' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:322: warning: unused parameter 'bb' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:328: warning: unused parameter 'thread' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:334: warning: unused parameter 'thread' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:340: warning: unused parameter 'cl' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: warning: unused parameter 'obj' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: warning: unused parameter 'thread' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: warning: unused parameter 'clazz' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: warning: unused parameter 'method' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: warning: unused parameter 'values' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: warning: unused parameter 'nonVirtual' /usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:357: warning: unused parameter 'clazz' make[3]: *** [gnu/classpath/jdwp/natVMVirtualMachine.lo] Error 1 make[3]: Leaving directory `/home/Marco/Desktop/compile-lin-win/gcc-build/i686-pc-mingw32/libjava' Attached my proposed patch to fix it. Once again a forgotten "JNICALL". Please guys, remember the JNICALLs! They're not necessary for Linux but at least minGW needs them... Changelog: * gnu/classpath/jdwp/natVMVirtualMachine.cc (jdwpVMInitCB): Added forgotten "JNICALL" Marco > Keith > > ChangeLog > 2007-01-15 Keith Seitz <keiths@redhat.com> > > * gnu/classpath/jdwp/natVMVirtualMachine.cc (DEFINE_CALLBACK): > New macro. > (ENABLE_EVENT): New macro. > (initialize): Define and enable JVMTI VM_INIT callback. > (jdwpVMInitCB): New function. > > > ------------------------------------------------------------------------ > > Index: gnu/classpath/jdwp/natVMVirtualMachine.cc > =================================================================== > --- gnu/classpath/jdwp/natVMVirtualMachine.cc (revision 120805) > +++ gnu/classpath/jdwp/natVMVirtualMachine.cc (working copy) > @@ -24,10 +24,12 @@ > #include <java/util/Hashtable.h> > #include <java/util/Iterator.h> > > +#include <gnu/classpath/jdwp/Jdwp.h> > #include <gnu/classpath/jdwp/VMFrame.h> > #include <gnu/classpath/jdwp/VMMethod.h> > #include <gnu/classpath/jdwp/VMVirtualMachine.h> > #include <gnu/classpath/jdwp/event/EventRequest.h> > +#include <gnu/classpath/jdwp/event/VmInitEvent.h> > #include <gnu/classpath/jdwp/exception/JdwpInternalErrorException.h> > #include <gnu/classpath/jdwp/util/MethodResult.h> > > @@ -35,6 +37,13 @@ > using namespace gnu::classpath::jdwp::event; > using namespace gnu::classpath::jdwp::util; > > +// Forward declarations > +static void jdwpVMInitCB (jvmtiEnv *env, JNIEnv *jni_env, jthread thread); > + > +#define DEFINE_CALLBACK(Cb,Event) Cb.Event = jdwp ## Event ## CB > +#define ENABLE_EVENT(Event,Thread) \ > + _jdwp_jvmtiEnv->SetEventNotificationMode (JVMTI_ENABLE, \ > + JVMTI_EVENT_ ## Event, Thread) > // JVMTI environment > static jvmtiEnv *_jdwp_jvmtiEnv; > > @@ -44,6 +53,12 @@ > _jdwp_suspend_counts = new ::java::util::Hashtable (); > JavaVM *vm = _Jv_GetJavaVM (); > vm->GetEnv (reinterpret_cast<void **> (&_jdwp_jvmtiEnv), JVMTI_VERSION_1_0); > + > + // Wait for VM_INIT to do more initialization > + jvmtiEventCallbacks callbacks; > + DEFINE_CALLBACK (callbacks, VMInit); > + _jdwp_jvmtiEnv->SetEventCallbacks (&callbacks, sizeof (callbacks)); > + ENABLE_EVENT (VM_INIT, NULL); > } > > void > @@ -343,3 +358,13 @@ > { > return NULL; > } > + > +static void > +jdwpVMInitCB (MAYBE_UNUSED jvmtiEnv *env, MAYBE_UNUSED JNIEnv *jni_env, > + jthread thread) > +{ > + // Send JDWP VMInit > + using namespace gnu::classpath::jdwp::event; > + Thread *init_thread = reinterpret_cast<Thread *> (thread); > + gnu::classpath::jdwp::Jdwp::notify (new VmInitEvent (init_thread)); > +} [-- Attachment #2: patch.txt --] [-- Type: text/plain, Size: 777 bytes --] Index: gnu/classpath/jdwp/natVMVirtualMachine.cc =================================================================== --- gnu/classpath/jdwp/natVMVirtualMachine.cc (revision 120933) +++ gnu/classpath/jdwp/natVMVirtualMachine.cc (working copy) @@ -38,7 +38,7 @@ using namespace gnu::classpath::jdwp::util; // Forward declarations -static void jdwpVMInitCB (jvmtiEnv *env, JNIEnv *jni_env, jthread thread); +static void JNICALL jdwpVMInitCB (jvmtiEnv *env, JNIEnv *jni_env, jthread thread); #define DEFINE_CALLBACK(Cb,Event) Cb.Event = jdwp ## Event ## CB #define ENABLE_EVENT(Event,Thread) \ @@ -359,7 +359,7 @@ return NULL; } -static void +static void JNICALL jdwpVMInitCB (MAYBE_UNUSED jvmtiEnv *env, MAYBE_UNUSED JNIEnv *jni_env, jthread thread) { ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 0:00 ` Marco Trudel @ 2007-01-19 0:03 ` Keith Seitz 2007-01-19 15:37 ` Tom Tromey 2007-01-19 0:05 ` Andrew Haley 1 sibling, 1 reply; 18+ messages in thread From: Keith Seitz @ 2007-01-19 0:03 UTC (permalink / raw) To: Marco Trudel; +Cc: Java Patch List Marco Trudel wrote: > Please guys, remember the JNICALLs! They're not necessary for Linux but > at least minGW needs them... Ugh, you know, and I really WAS being careful about that... I double-checked that all my functions did that -- all the JVMTI ones, at least. Sigh. Very sorry about that. Keith ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 0:03 ` Keith Seitz @ 2007-01-19 15:37 ` Tom Tromey 2007-01-19 17:56 ` Marco Trudel 0 siblings, 1 reply; 18+ messages in thread From: Tom Tromey @ 2007-01-19 15:37 UTC (permalink / raw) To: Keith Seitz; +Cc: Marco Trudel, Java Patch List >>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes: >> Please guys, remember the JNICALLs! They're not necessary for Linux >> but at least minGW needs them... Keith> Ugh, you know, and I really WAS being careful about that... I Keith> double-checked that all my functions did that -- all the JVMTI ones, Keith> at least. Sigh. Yeah, it can be hard to remember this when developing on Linux. Yesterday I was wondering whether there is some way we could define JNICALL on Linux so that we would catch this error, say some harmless attribute. But, that is probably a bad idea since JNICALL is public. Another idea would be to use a token-pasting "DEFUN" macro and let it do the work: #define DEFUN(blahblah) static jvmtiError JNICALL \ _Jv_JVMTI_ ## Name blahblah ... DEFUN(SuspendThread, (...)) { ... } But of course this is still susceptible to the problem if you forget to use the macro. Tom ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 15:37 ` Tom Tromey @ 2007-01-19 17:56 ` Marco Trudel 2007-01-19 18:11 ` David Daney ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Marco Trudel @ 2007-01-19 17:56 UTC (permalink / raw) To: tromey; +Cc: Keith Seitz, Java Patch List Tom Tromey wrote: >>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes: > >>> Please guys, remember the JNICALLs! They're not necessary for Linux >>> but at least minGW needs them... > > Keith> Ugh, you know, and I really WAS being careful about that... I > Keith> double-checked that all my functions did that -- all the JVMTI ones, > Keith> at least. Sigh. > > Yeah, it can be hard to remember this when developing on Linux. > > Yesterday I was wondering whether there is some way we could define > JNICALL on Linux so that we would catch this error, say some harmless > attribute. But, that is probably a bad idea since JNICALL is public. > > Another idea would be to use a token-pasting "DEFUN" macro and let it > do the work: > > #define DEFUN(blahblah) static jvmtiError JNICALL \ > _Jv_JVMTI_ ## Name blahblah > ... > DEFUN(SuspendThread, (...)) { ... } > > But of course this is still susceptible to the problem if you forget > to use the macro. Please allow me to somehow broaden the topic you started... Since I got involved with GCC/GCJ, I run into a lot of compilation errors. To do some unreliable mind-based statistics, I remember about 2 or 3 GCC problems (TLS, unfixed cygwin problem, one to fake the stats). When it comes to GCJ, I think at least every second time I tried to compile after a week or two of being away, compilation was broken. This is maybe about 30 times but more likely way more. Don't get me wrong, I'm not here to blame anyone. I'm very happy all you guys are developing so hard on gcj. I just wonder how the GCC staff are able to keep the quality so constant and gcj... well... unfortunately not that constant. Can we do something to change that? Interested for feedback... Marco ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 17:56 ` Marco Trudel @ 2007-01-19 18:11 ` David Daney 2007-01-19 18:23 ` Marco Trudel [not found] ` <45B108EF.2070601@redhat.com> 2007-01-20 0:02 ` Tom Tromey 2 siblings, 1 reply; 18+ messages in thread From: David Daney @ 2007-01-19 18:11 UTC (permalink / raw) To: Marco Trudel; +Cc: tromey, Keith Seitz, Java Patch List Marco Trudel wrote: > Tom Tromey wrote: >>>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes: >> >>>> Please guys, remember the JNICALLs! They're not necessary for Linux >>>> but at least minGW needs them... >> >> Keith> Ugh, you know, and I really WAS being careful about that... I >> Keith> double-checked that all my functions did that -- all the JVMTI >> ones, >> Keith> at least. Sigh. >> >> Yeah, it can be hard to remember this when developing on Linux. >> >> Yesterday I was wondering whether there is some way we could define >> JNICALL on Linux so that we would catch this error, say some harmless >> attribute. But, that is probably a bad idea since JNICALL is public. >> >> Another idea would be to use a token-pasting "DEFUN" macro and let it >> do the work: >> >> #define DEFUN(blahblah) static jvmtiError JNICALL \ >> _Jv_JVMTI_ ## Name blahblah >> ... >> DEFUN(SuspendThread, (...)) { ... } >> >> But of course this is still susceptible to the problem if you forget >> to use the macro. > > Please allow me to somehow broaden the topic you started... > Since I got involved with GCC/GCJ, I run into a lot of compilation > errors. To do some unreliable mind-based statistics, I remember about 2 > or 3 GCC problems (TLS, unfixed cygwin problem, one to fake the stats). > When it comes to GCJ, I think at least every second time I tried to > compile after a week or two of being away, compilation was broken. This > is maybe about 30 times but more likely way more. > Don't get me wrong, I'm not here to blame anyone. I'm very happy all you > guys are developing so hard on gcj. I just wonder how the GCC staff are > able to keep the quality so constant and gcj... well... unfortunately > not that constant. Can we do something to change that? > > Interested for feedback... You are kind of comparing apples to oranges. Most of the changes in the GCC core have to do with code generation. And as such don't usually effect the interaction between the OS and the language runtime. Many of the changes in libgcj have to do with the interaction of the runtime with the OS. There is potential for breakage here much more often. The fact that most of the developers are working under Linux means that the changes don't get tested against mingw. I appreciate the fact that you are fixing things, but I don't think you can expect much testing on mingw to be done by others. So the situation is likely to continue. I guess I have not real suggestion about how to improve things, only excuses as to why they are as they are. David Daney ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 18:11 ` David Daney @ 2007-01-19 18:23 ` Marco Trudel 2007-01-19 18:35 ` David Daney 0 siblings, 1 reply; 18+ messages in thread From: Marco Trudel @ 2007-01-19 18:23 UTC (permalink / raw) To: David Daney; +Cc: tromey, Keith Seitz, Java Patch List David Daney wrote: > Marco Trudel wrote: >> Tom Tromey wrote: >>>>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes: >>> >>>>> Please guys, remember the JNICALLs! They're not necessary for Linux >>>>> but at least minGW needs them... >>> >>> Keith> Ugh, you know, and I really WAS being careful about that... I >>> Keith> double-checked that all my functions did that -- all the JVMTI >>> ones, >>> Keith> at least. Sigh. >>> >>> Yeah, it can be hard to remember this when developing on Linux. >>> >>> Yesterday I was wondering whether there is some way we could define >>> JNICALL on Linux so that we would catch this error, say some harmless >>> attribute. But, that is probably a bad idea since JNICALL is public. >>> >>> Another idea would be to use a token-pasting "DEFUN" macro and let it >>> do the work: >>> >>> #define DEFUN(blahblah) static jvmtiError JNICALL \ >>> _Jv_JVMTI_ ## Name blahblah >>> ... >>> DEFUN(SuspendThread, (...)) { ... } >>> >>> But of course this is still susceptible to the problem if you forget >>> to use the macro. >> >> Please allow me to somehow broaden the topic you started... >> Since I got involved with GCC/GCJ, I run into a lot of compilation >> errors. To do some unreliable mind-based statistics, I remember about >> 2 or 3 GCC problems (TLS, unfixed cygwin problem, one to fake the >> stats). When it comes to GCJ, I think at least every second time I >> tried to compile after a week or two of being away, compilation was >> broken. This is maybe about 30 times but more likely way more. >> Don't get me wrong, I'm not here to blame anyone. I'm very happy all >> you guys are developing so hard on gcj. I just wonder how the GCC >> staff are able to keep the quality so constant and gcj... well... >> unfortunately not that constant. Can we do something to change that? >> >> Interested for feedback... > > You are kind of comparing apples to oranges. Most of the changes in the > GCC core have to do with code generation. And as such don't usually > effect the interaction between the OS and the language runtime. > > Many of the changes in libgcj have to do with the interaction of the > runtime with the OS. There is potential for breakage here much more > often. Good point! > The fact that most of the developers are working under Linux > means that the changes don't get tested against mingw. I appreciate the > fact that you are fixing things, but I don't think you can expect much > testing on mingw to be done by others. So the situation is likely to > continue. Don't get me wrong, I'm not only talking about mingw. I'm talking about compiling in general. But I think the main problem really is cross-compiling as you imply. For instance, the current trunk is broken for all cross-compilations where build != host and where build can't run binaries from host :-( > I guess I have not real suggestion about how to improve things, only > excuses as to why they are as they are. That's ok. You're pushing the discussion, thats good :-) But I think you're right. We're probably keeping the situation. After all, it's not that bad... Marco ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 18:23 ` Marco Trudel @ 2007-01-19 18:35 ` David Daney 0 siblings, 0 replies; 18+ messages in thread From: David Daney @ 2007-01-19 18:35 UTC (permalink / raw) To: Marco Trudel; +Cc: tromey, Keith Seitz, Java Patch List Marco Trudel wrote: > Don't get me wrong, I'm not only talking about mingw. I'm talking about > compiling in general. But I think the main problem really is > cross-compiling as you imply. For instance, the current trunk is broken > for all cross-compilations where build != host and where build can't run > binaries from host :-( > I used to do many more mipsel-linux cross compiles, but have lately taken to doing native builds on that target. Perhaps I should start doing more cross builds. I will put it on my to-do list. David Daney ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <45B108EF.2070601@redhat.com>]
* Re: [RFA] Add JDWP VM_INIT JVMTI callback [not found] ` <45B108EF.2070601@redhat.com> @ 2007-01-19 18:18 ` Marco Trudel 0 siblings, 0 replies; 18+ messages in thread From: Marco Trudel @ 2007-01-19 18:18 UTC (permalink / raw) To: Keith Seitz, Java Patch List I sent this to the patches list as well. I assume Keith just hit the wrong button in the mail application: Keith Seitz wrote: > Marco Trudel wrote: > >>> Keith> Ugh, you know, and I really WAS being careful about that... I >>> Keith> double-checked that all my functions did that -- all the JVMTI >>> ones, >>> Keith> at least. Sigh. > > And starting today, I'm turning a new leaf. Before I commit any patch, I > will verify that it builds with a linux-mingw32 cross compiler. [Okay, > actually, starting later today when it "finishes" building.] I don't know if thats a good solution. I'm sure you can use your time better than that. What about a regularly cross-compilation session where error reports are sent to the list and the responsible guys try to fix problems? No, not that a good idea I guess... Marco ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 17:56 ` Marco Trudel 2007-01-19 18:11 ` David Daney [not found] ` <45B108EF.2070601@redhat.com> @ 2007-01-20 0:02 ` Tom Tromey 2007-01-20 12:28 ` Marco Trudel 2 siblings, 1 reply; 18+ messages in thread From: Tom Tromey @ 2007-01-20 0:02 UTC (permalink / raw) To: Marco Trudel; +Cc: Keith Seitz, Java Patch List >>>>> "Marco" == Marco Trudel <mtrudel@gmx.ch> writes: Marco> I just wonder how the GCC Marco> staff are able to keep the quality so constant and Marco> gcj... well... unfortunately not that constant. You're doing probably the hardest build there is: a Canadian cross targeting Windows. The core gcj developers generally are doing native builds, and not many gcj developers use Windows; also the ones who do use Windows tend to be less active. Finally, we're in a time where gcj is changing rapidly, which makes the ordinary background problem worse. That's the explanation for how it is... but: Marco> Can we do something to change that? Yes, I think so. One thing we could do is set up an automated tester on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm) that does a build like yours. That way breakage would be noticed more quickly. Would you be able to set something up? I may be able to help a bit; we could take some infrastructure stuff from the Classpath builder. Tom ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-20 0:02 ` Tom Tromey @ 2007-01-20 12:28 ` Marco Trudel 2007-01-20 18:33 ` Tom Tromey 0 siblings, 1 reply; 18+ messages in thread From: Marco Trudel @ 2007-01-20 12:28 UTC (permalink / raw) To: tromey; +Cc: Keith Seitz, Java Patch List Tom Tromey wrote: >>>>>> "Marco" == Marco Trudel <mtrudel@gmx.ch> writes: > > Marco> I just wonder how the GCC > Marco> staff are able to keep the quality so constant and > Marco> gcj... well... unfortunately not that constant. > > You're doing probably the hardest build there is: a Canadian cross > targeting Windows. The core gcj developers generally are doing native > builds, and not many gcj developers use Windows; also the ones who do > use Windows tend to be less active. Finally, we're in a time where > gcj is changing rapidly, which makes the ordinary background problem > worse. Yes. Andrew also said it quite adequate: We're in "rapid development" mode at the moment. In my opinion, progress is more worthy than stability and I'm glad GCJ is being worked so hard on. > That's the explanation for how it is... but: > > Marco> Can we do something to change that? > > Yes, I think so. One thing we could do is set up an automated tester > on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm) that > does a build like yours. That way breakage would be noticed more quickly. > > Would you be able to set something up? I may be able to help a bit; > we could take some infrastructure stuff from the Classpath builder. Very interesting. I was thinking about something like that for a long time but didn't knew that there is already infrastructure around. I would suggest to: - regularly try to compile a host=Linux target=mingw and host=mingw target=mingw compiler. Now what is regularly? What makes sense? Every day? Every second day? Once a week? - If it failes: email notification. To who? Me? GCJ list? I'd be interested in setting up a mingw-testing account and maintaining it. This could really help keeping things working. Thanks for the Idea Marco ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-20 12:28 ` Marco Trudel @ 2007-01-20 18:33 ` Tom Tromey 0 siblings, 0 replies; 18+ messages in thread From: Tom Tromey @ 2007-01-20 18:33 UTC (permalink / raw) To: Marco Trudel; +Cc: Keith Seitz, Java Patch List >>>>> "Marco" == Marco Trudel <mtrudel@gmx.ch> writes: >> Yes, I think so. One thing we could do is set up an automated tester >> on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm) that >> does a build like yours. Marco> - regularly try to compile a host=Linux target=mingw and host=mingw Marco> target=mingw compiler. Now what is regularly? What makes sense? Every Marco> day? Every second day? Once a week? For the Classpath builder (http://builder.classpath.org) we simply do continuous build cycles. I think there's a 30 minute delay, or something short like that, between the end of one build and the start of the next. Marco> - If it failes: email notification. To who? Me? GCJ list? We could set up a new list, or re-use an existing one -- perhaps the Classpath build list. Geoff's old tester used to just send email to anyone who might have broken the build, those scripts might be in gcc/contrib. For Classpath we also have an irc bot that you can query to get the status. This sort of thing is surprisingly easy to set up. We could for instance have a bot that says something when a build fails. Tom ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 0:00 ` Marco Trudel 2007-01-19 0:03 ` Keith Seitz @ 2007-01-19 0:05 ` Andrew Haley 2007-01-19 1:31 ` Keith Seitz 1 sibling, 1 reply; 18+ messages in thread From: Andrew Haley @ 2007-01-19 0:05 UTC (permalink / raw) To: Marco Trudel; +Cc: Keith Seitz, Java Patch List Marco Trudel writes: > Keith Seitz wrote: > > Hi, > > > > This patch adds a JVMTI VM_INIT callback to be used by the JDWP code. > > Currently this function simply sends the JDWP VM_INIT event > > notification, but later it will do install additional JVMTI callbacks > > for all the various JDWP event notifications. > > > > Comments/questions/concerns? Keith: as well as Marco's fixes, please fix your warnings. Andrew. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 0:05 ` Andrew Haley @ 2007-01-19 1:31 ` Keith Seitz 2007-01-19 15:40 ` Tom Tromey 0 siblings, 1 reply; 18+ messages in thread From: Keith Seitz @ 2007-01-19 1:31 UTC (permalink / raw) To: Andrew Haley; +Cc: Java Patch List [-- Attachment #1: Type: text/plain, Size: 866 bytes --] Andrew Haley wrote: > Keith: as well as Marco's fixes, please fix your warnings. Okay, I've committed Marco's fix. Here's a patch which removes the warnings and does some reformatting of the long lines (and other really minor whitespace stuff that indent found). However, it contains a lot of method decls like: jint gnu::classpath::jdwp:: some_method (MAYBE_UNUSED type1 argument1, MAYBE_UNUSED type2 argument2, MAYBE_UNUSED type3 argument3) { // ... } and such. Indent was very inconsistent about how to format some of these lines, so I chose the one I thought looked the best. Any suggestions on how to clean these long lines up better or is this sufficient? Keith ChangeLog 2007-01-18 Keith Seitz <keiths@redhat.com> * gnu/classpath/jdwp/natVMVirtualMachine.cc: Mark unused parameters in methods and reformat. [-- Attachment #2: natvmvm-reformat.patch --] [-- Type: text/x-patch, Size: 3671 bytes --] Index: gnu/classpath/jdwp/natVMVirtualMachine.cc =================================================================== --- gnu/classpath/jdwp/natVMVirtualMachine.cc (revision 120946) +++ gnu/classpath/jdwp/natVMVirtualMachine.cc (working copy) @@ -62,7 +62,7 @@ } void -gnu::classpath::jdwp::VMVirtualMachine ::suspendThread (Thread *thread) +gnu::classpath::jdwp::VMVirtualMachine::suspendThread (Thread *thread) { jint value; Integer *count; @@ -213,7 +213,7 @@ case EventRequest::EVENT_VM_INIT: break; - + case EventRequest::EVENT_VM_DEATH: break; } @@ -244,7 +244,7 @@ case EventRequest::EVENT_THREAD_END: break; - + case EventRequest::EVENT_CLASS_PREPARE: break; @@ -268,14 +268,14 @@ case EventRequest::EVENT_VM_INIT: break; - + case EventRequest::EVENT_VM_DEATH: break; } } void -gnu::classpath::jdwp::VMVirtualMachine::clearEvents (jbyte kind) +gnu::classpath::jdwp::VMVirtualMachine::clearEvents (MAYBE_UNUSED jbyte kind) { } @@ -292,69 +292,75 @@ } jint -gnu::classpath::jdwp::VMVirtualMachine::getClassStatus (jclass klass) +gnu::classpath::jdwp::VMVirtualMachine:: +getClassStatus (MAYBE_UNUSED jclass klass) { return 0; } JArray<gnu::classpath::jdwp::VMMethod *> * -gnu::classpath::jdwp::VMVirtualMachine::getAllClassMethods (jclass klass) +gnu::classpath::jdwp::VMVirtualMachine:: +getAllClassMethods (MAYBE_UNUSED jclass klass) { return NULL; } gnu::classpath::jdwp::VMMethod * -gnu::classpath::jdwp::VMVirtualMachine::getClassMethod (jclass klass, jlong id) +gnu::classpath::jdwp::VMVirtualMachine:: +getClassMethod (MAYBE_UNUSED jclass klass, MAYBE_UNUSED jlong id) { return NULL; } java::util::ArrayList * -gnu::classpath::jdwp::VMVirtualMachine::getFrames (Thread *thread, - jint start, - jint length) +gnu::classpath::jdwp::VMVirtualMachine::getFrames (MAYBE_UNUSED Thread *thread, + MAYBE_UNUSED jint start, + MAYBE_UNUSED jint length) { return NULL; } gnu::classpath::jdwp::VMFrame * -gnu::classpath::jdwp::VMVirtualMachine::getFrame (Thread *thread, - ::java::nio::ByteBuffer *bb) +gnu::classpath::jdwp::VMVirtualMachine:: +getFrame (MAYBE_UNUSED Thread *thread, MAYBE_UNUSED::java::nio::ByteBuffer *bb) { return NULL; } jint -gnu::classpath::jdwp::VMVirtualMachine::getFrameCount (Thread *thread) +gnu::classpath::jdwp::VMVirtualMachine:: +getFrameCount (MAYBE_UNUSED Thread *thread) { return 0; } jint -gnu::classpath::jdwp::VMVirtualMachine::getThreadStatus (Thread *thread) +gnu::classpath::jdwp::VMVirtualMachine:: +getThreadStatus (MAYBE_UNUSED Thread *thread) { return 0; } java::util::ArrayList * -gnu::classpath::jdwp::VMVirtualMachine::getLoadRequests (ClassLoader *cl) +gnu::classpath::jdwp::VMVirtualMachine:: +getLoadRequests (MAYBE_UNUSED ClassLoader *cl) { return NULL; } MethodResult * -gnu::classpath::jdwp::VMVirtualMachine::executeMethod (jobject obj, - Thread *thread, - jclass clazz, - reflect::Method *method, - jobjectArray values, - jboolean nonVirtual) +gnu::classpath::jdwp::VMVirtualMachine:: +executeMethod (MAYBE_UNUSED jobject obj, MAYBE_UNUSED Thread *thread, + MAYBE_UNUSED jclass clazz, MAYBE_UNUSED reflect::Method *method, + MAYBE_UNUSED jobjectArray values, + MAYBE_UNUSED jboolean nonVirtual) { return NULL; } jstring -gnu::classpath::jdwp::VMVirtualMachine::getSourceFile (jclass clazz) +gnu::classpath::jdwp::VMVirtualMachine:: +getSourceFile (MAYBE_UNUSED jclass clazz) { return NULL; } ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 1:31 ` Keith Seitz @ 2007-01-19 15:40 ` Tom Tromey 2007-01-19 17:27 ` Keith Seitz 0 siblings, 1 reply; 18+ messages in thread From: Tom Tromey @ 2007-01-19 15:40 UTC (permalink / raw) To: Keith Seitz; +Cc: Andrew Haley, Java Patch List >>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes: Keith> Any suggestions on how to clean these long lines up better or is this Keith> sufficient? I think this is sufficient. It is also ok if the occasional line goes over 80 chars. Tom ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [RFA] Add JDWP VM_INIT JVMTI callback 2007-01-19 15:40 ` Tom Tromey @ 2007-01-19 17:27 ` Keith Seitz 0 siblings, 0 replies; 18+ messages in thread From: Keith Seitz @ 2007-01-19 17:27 UTC (permalink / raw) To: Java Patch List Tom Tromey wrote: >>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes: > > Keith> Any suggestions on how to clean these long lines up better or is this > Keith> sufficient? > > I think this is sufficient. > It is also ok if the occasional line goes over 80 chars. Okay, I've committed this patch. I see that natVMFrame.cc is also suffers from a similar problem. I will post and commit a separate patch for that. Keith ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2007-01-20 18:33 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-01-16 6:40 [RFA] Add JDWP VM_INIT JVMTI callback Keith Seitz 2007-01-16 19:38 ` Tom Tromey 2007-01-16 19:54 ` Keith Seitz 2007-01-19 0:00 ` Marco Trudel 2007-01-19 0:03 ` Keith Seitz 2007-01-19 15:37 ` Tom Tromey 2007-01-19 17:56 ` Marco Trudel 2007-01-19 18:11 ` David Daney 2007-01-19 18:23 ` Marco Trudel 2007-01-19 18:35 ` David Daney [not found] ` <45B108EF.2070601@redhat.com> 2007-01-19 18:18 ` Marco Trudel 2007-01-20 0:02 ` Tom Tromey 2007-01-20 12:28 ` Marco Trudel 2007-01-20 18:33 ` Tom Tromey 2007-01-19 0:05 ` Andrew Haley 2007-01-19 1:31 ` Keith Seitz 2007-01-19 15:40 ` Tom Tromey 2007-01-19 17:27 ` Keith Seitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).