From ted at tedneward.com Wed Aug 1 00:47:10 2007 From: ted at tedneward.com (Ted Neward) Date: Wed, 1 Aug 2007 00:47:10 -0700 Subject: Question In-Reply-To: <46254954.6000707@Sun.COM> Message-ID: <003f01c7d410$74deeb40$802ca8c0@XPWork> Two questions: (*) Are we any further on this? (*) What about disassembly under Linux or Solaris? Anybody have good suggestions for a disassembler to use for -XX:+PrintAssembly? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Chuck.Rasbold at Sun.COM [mailto:Chuck.Rasbold at Sun.COM] > Sent: Tuesday, April 17, 2007 3:25 PM > To: Ted Neward > Cc: hotspot-compiler-dev at openjdk.dev.java.net > Subject: Re: Question > > I can't apologize enough on how long this is taking. We still working on > it. > > -- Chuck > > Ted Neward wrote: > > Any followup here? I'm still hoping to get the one that Sun uses, rather > > than spend the energy/time/effort to write my own.... > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > >>-----Original Message----- > >>From: Ted Neward [mailto:ted at tedneward.com] > >>Sent: Monday, January 15, 2007 4:30 PM > >>To: hotspot-compiler-dev at openjdk.dev.java.net > >>Subject: RE: Question > >> > >>Any word on getting this thing open-sourced? I know it's probably > possible > >>to build one for myself, but.... Oy. Would *much* rather not have to do > >>that. > >> > >>Ted Neward > >>Java, .NET, XML Services > >>Consulting, Teaching, Speaking, Writing > >>http://www.tedneward.com > >> > >> > >> > >>>-----Original Message----- > >>>From: Chuck.Rasbold at Sun.COM [mailto:Chuck.Rasbold at Sun.COM] > >>>Sent: Thursday, December 07, 2006 2:44 PM > >>>To: hotspot-compiler-dev at openjdk.dev.java.net > >>>Subject: Re: Question > >>> > >>>Sun has a disassembler which is based on the disassembler source code > >> > >>from > >> > >>>a gdb > >>>of many years past. > >>> > >>>The disassembler is built into a .so or .dll. Typically, I place that > >>>disassembler.so file in the same directory as the libjvm.so of > interest. > >>>Other > >>>times, on Solaris, I will set my LD_LIBRARY_PATH to include the > >> > >>directory > >> > >>>where > >>>the .so resides. I'm not much of a Windows guy, so I can't advise you > >>>there. > >>> > >>>Until now, the disassembler source has been kept separate from the > >> > >>HotSpot > >> > >>>source tree and the binary not distributed to customers in order to > >> > >>avoid > >> > >>>the > >>>complications that would be incurred by Sun due to the GPL. > >>> > >>>Of course, the world is now different and due to an oversight, it was > >> > >>not > >> > >>>included when HotSpot was open sourced. We're currently working on > >>>getting it > >>>distributed with HotSpot. > >>> > >>>Hopefully, I've made things a bit clearer. > >>> > >>>-- Chuck > >>> > >>>Ted Neward wrote: > >>> > >>>>So help me out here, if you don't mind--when you say I will "need the > >>>>disassembler", you're saying I have to download (what?) and put it > >>> > >>>(where?)? > >>> > >>>>Unfortunately, the link you sent, Steve, doesn't say much beyond that > >>> > >>>fact > >>> > >>>>that the poster hacked it--I'm not sure what to do with it once I find > >>> > >>>it. > >>> > >>>>Can I grab the GNU disassembler and use it, since I'm not in the same > >>> > >>>boat > >>> > >>>>as Sun re: licensning and distribution issues? > >>>> > >>>>Bear in mind, I want to do this under Windows if I can; I dunno if > >> > >>that > >> > >>>>makes a difference. > >>>> > >>>>Sorry for being such the noob, but one hope I have is to sort through > >>> > >>>all > >>> > >>>>this and put it into an article or paper or presentation and help > >> > >>others > >> > >>>to > >>> > >>>>get into seeing all this stuff without having to wade through the same > >>> > >>>steps > >>> > >>>>by hand. :-) > >>>> > >>>>Ted Neward > >>>>Java, .NET, XML Services > >>>>Consulting, Teaching, Speaking, Writing > >>>>http://www.tedneward.com > >>>> > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Peter.Kessler at Sun.COM [mailto:Peter.Kessler at Sun.COM] > >>>>>Sent: Tuesday, December 05, 2006 11:57 AM > >>>>>To: hotspot-compiler-dev at openjdk.dev.java.net > >>>>>Subject: Re: Question > >>>>> > >>>>>steve goldman wrote: > >>>>> > >>>>> > >>>>>>Ted Neward wrote: > >>>>>> > >>>>>> > >>>>>>>So one thing I?d like to see (via console output or some other > >>>>>>>out-of-band > >>>>>>>form of view) is the code generated by the JIT compiler when it > JITs > >> > >>a > >> > >>>>>>>method. What?s the best way for doing so? > >>>>>>> > >>>>>>> > >>>>>> > >>>>>>You need two things, a "develop" version of hotspot and the > >>>>>>disassembler. There is a flag -XX:+PrintAssembly which will attempt > >> > >>to > >> > >>>>>>dynamically load the disassembler and as various code blobs are > >>>>>>generated will invoke the disassembler. The product version of > >> > >>hotspot > >> > >>>>>>doesn't enable this flag so you need to build a version that isn't > >> > >>the > >> > >>>>>>product (or convert the switch from "develop" to "product"). In any > >>> > >>>case > >>> > >>>>>>I think you'll have to build the jvm. Additionally you need the > >>>>>>disassembler. Unfortunately that got left out of the initial source > >>>>>>release. The disassembler we use is based on the gnu disassembler > and > >>>>>>because it was gpl before hotspot was gpl'd it was kept separate > from > >>>>>>the hotspot code. That should be fixed soon I'd guess. There was a > >> > >>note > >> > >>>>>>here > >>>>>>http://c1.complang.tuwien.ac.at/pipermail/cacao/2006- > >>>>> > >>>>>November/000195.html > >>>>> > >>>>> > >>>>>>where someone hacked the cacao disassembler to get around this. The > >>>>>>disassembler you build (.dll or .so) needs to go into the jvm (or > >>>>>>somewhere in your LD_LIBRARY_PATH or equivalent) were it will get > >>>>> > >>>>>loaded. > >>>>> > >>>>> > >>>>>>With the server version of hotspot there is another develop flag > >>>>>>-XX:+PrintOptoAssembly which will print a very stylized version of > >> > >>the > >> > >>>>>>code the jit produces. It will do this without the disassembler > being > >>>>>>present. > >>>>> > >>>>>You can also use the "fastdebug" version of HotSpot to get > >>>>>access to the -XX:+PrintAssembly flag. The fastdebug version > >>>>>is built as part of the "make world" target. You still need > >>>>>the dissassembler, as Steve says. > >>>>> > >>>>> ... peter > >>>>> > >>>>>-- > >>>>>No virus found in this incoming message. > >>>>>Checked by AVG Free Edition. > >>>>>Version: 7.5.432 / Virus Database: 268.15.9/573 - Release Date: > >>> > >>>12/5/2006 > >>> > >>>>>4:07 PM > >>>>> > >>>> > >>>> > >>>-- > >>>No virus found in this incoming message. > >>>Checked by AVG Free Edition. > >>>Version: 7.5.432 / Virus Database: 268.15.15/579 - Release Date: > >> > >>12/7/2006 > >> > >>>1:31 PM > >>> > >> > >>-- > >>No virus found in this outgoing message. > >>Checked by AVG Free Edition. > >>Version: 7.5.432 / Virus Database: 268.16.12/628 - Release Date: > 1/15/2007 > >>11:04 AM > >> > >> > >>-- > >>No virus found in this incoming message. > >>Checked by AVG Free Edition. > >>Version: 7.5.432 / Virus Database: 268.16.12/628 - Release Date: > 1/15/2007 > >>11:04 AM > >> > > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.446 / Virus Database: 269.4.0/762 - Release Date: 4/15/2007 > 4:22 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: 7/31/2007 5:26 PM From Chuck.Rasbold at Sun.COM Thu Aug 2 15:38:44 2007 From: Chuck.Rasbold at Sun.COM (Chuck Rasbold) Date: Thu, 02 Aug 2007 15:38:44 -0700 Subject: Question In-Reply-To: <003f01c7d410$74deeb40$802ca8c0@XPWork> References: <003f01c7d410$74deeb40$802ca8c0@XPWork> Message-ID: <46B25CF4.2050805@Sun.COM> Ted - In early July, Sun's legal department gave the OK to open source a disassembler based on GNU binutils 2.17. Any delay in progress since then is purely my own fault, as I have been attending to other engineering duties. Based on advice I received so far, the plan is to start an OpenJDK subproject, and distribute the disassembler as a set of diffs and additions to the latest GNU binutils. To use with +PrintAssembly, one would get binutils, apply the source patches, build using the supplied makefile into a .dll or .so, and install the library into a known location. Internally, I still need to do some cleanup and testing of the disassembler...hopefully I haven't broken it moving it forward to 2.17. Externally, I need to figure out how the OpenJDK process works, and make sure the distribution and packaging method is reasonable. I am a novice in the open source world, and recommendations from those more experienced than me are welcome. -- Chuck Ted Neward wrote: > Two questions: > (*) Are we any further on this? > (*) What about disassembly under Linux or Solaris? Anybody have good > suggestions for a disassembler to use for -XX:+PrintAssembly? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > >>-----Original Message----- >>From: Chuck.Rasbold at Sun.COM [mailto:Chuck.Rasbold at Sun.COM] >>Sent: Tuesday, April 17, 2007 3:25 PM >>To: Ted Neward >>Cc: hotspot-compiler-dev at openjdk.dev.java.net >>Subject: Re: Question >> >>I can't apologize enough on how long this is taking. We still working on >>it. >> >>-- Chuck >> >>Ted Neward wrote: >> >>>Any followup here? I'm still hoping to get the one that Sun uses, rather >>>than spend the energy/time/effort to write my own.... >>> >>>Ted Neward >>>Java, .NET, XML Services >>>Consulting, Teaching, Speaking, Writing >>>http://www.tedneward.com >>> >>> >>> >>>>-----Original Message----- >>>>From: Ted Neward [mailto:ted at tedneward.com] >>>>Sent: Monday, January 15, 2007 4:30 PM >>>>To: hotspot-compiler-dev at openjdk.dev.java.net >>>>Subject: RE: Question >>>> >>>>Any word on getting this thing open-sourced? I know it's probably >> >>possible >> >>>>to build one for myself, but.... Oy. Would *much* rather not have to do >>>>that. >>>> >>>>Ted Neward >>>>Java, .NET, XML Services >>>>Consulting, Teaching, Speaking, Writing >>>>http://www.tedneward.com >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Chuck.Rasbold at Sun.COM [mailto:Chuck.Rasbold at Sun.COM] >>>>>Sent: Thursday, December 07, 2006 2:44 PM >>>>>To: hotspot-compiler-dev at openjdk.dev.java.net >>>>>Subject: Re: Question >>>>> >>>>>Sun has a disassembler which is based on the disassembler source code >>>> >>>>from >>>> >>>> >>>>>a gdb >>>>>of many years past. >>>>> >>>>>The disassembler is built into a .so or .dll. Typically, I place that >>>>>disassembler.so file in the same directory as the libjvm.so of >> >>interest. >> >>>>>Other >>>>>times, on Solaris, I will set my LD_LIBRARY_PATH to include the >>>> >>>>directory >>>> >>>> >>>>>where >>>>>the .so resides. I'm not much of a Windows guy, so I can't advise you >>>>>there. >>>>> >>>>>Until now, the disassembler source has been kept separate from the >>>> >>>>HotSpot >>>> >>>> >>>>>source tree and the binary not distributed to customers in order to >>>> >>>>avoid >>>> >>>> >>>>>the >>>>>complications that would be incurred by Sun due to the GPL. >>>>> >>>>>Of course, the world is now different and due to an oversight, it was >>>> >>>>not >>>> >>>> >>>>>included when HotSpot was open sourced. We're currently working on >>>>>getting it >>>>>distributed with HotSpot. >>>>> >>>>>Hopefully, I've made things a bit clearer. >>>>> >>>>>-- Chuck >>>>> >>>>>Ted Neward wrote: >>>>> >>>>> >>>>>>So help me out here, if you don't mind--when you say I will "need the >>>>>>disassembler", you're saying I have to download (what?) and put it >>>>> >>>>>(where?)? >>>>> >>>>> >>>>>>Unfortunately, the link you sent, Steve, doesn't say much beyond that >>>>> >>>>>fact >>>>> >>>>> >>>>>>that the poster hacked it--I'm not sure what to do with it once I find >>>>> >>>>>it. >>>>> >>>>> >>>>>>Can I grab the GNU disassembler and use it, since I'm not in the same >>>>> >>>>>boat >>>>> >>>>> >>>>>>as Sun re: licensning and distribution issues? >>>>>> >>>>>>Bear in mind, I want to do this under Windows if I can; I dunno if >>>> >>>>that >>>> >>>> >>>>>>makes a difference. >>>>>> >>>>>>Sorry for being such the noob, but one hope I have is to sort through >>>>> >>>>>all >>>>> >>>>> >>>>>>this and put it into an article or paper or presentation and help >>>> >>>>others >>>> >>>> >>>>>to >>>>> >>>>> >>>>>>get into seeing all this stuff without having to wade through the same >>>>> >>>>>steps >>>>> >>>>> >>>>>>by hand. :-) >>>>>> >>>>>>Ted Neward >>>>>>Java, .NET, XML Services >>>>>>Consulting, Teaching, Speaking, Writing >>>>>>http://www.tedneward.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Peter.Kessler at Sun.COM [mailto:Peter.Kessler at Sun.COM] >>>>>>>Sent: Tuesday, December 05, 2006 11:57 AM >>>>>>>To: hotspot-compiler-dev at openjdk.dev.java.net >>>>>>>Subject: Re: Question >>>>>>> >>>>>>>steve goldman wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Ted Neward wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>So one thing I?d like to see (via console output or some other >>>>>>>>>out-of-band >>>>>>>>>form of view) is the code generated by the JIT compiler when it >> >>JITs >> >>>>a >>>> >>>> >>>>>>>>>method. What?s the best way for doing so? >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>You need two things, a "develop" version of hotspot and the >>>>>>>>disassembler. There is a flag -XX:+PrintAssembly which will attempt >>>> >>>>to >>>> >>>> >>>>>>>>dynamically load the disassembler and as various code blobs are >>>>>>>>generated will invoke the disassembler. The product version of >>>> >>>>hotspot >>>> >>>> >>>>>>>>doesn't enable this flag so you need to build a version that isn't >>>> >>>>the >>>> >>>> >>>>>>>>product (or convert the switch from "develop" to "product"). In any >>>>> >>>>>case >>>>> >>>>> >>>>>>>>I think you'll have to build the jvm. Additionally you need the >>>>>>>>disassembler. Unfortunately that got left out of the initial source >>>>>>>>release. The disassembler we use is based on the gnu disassembler >> >>and >> >>>>>>>>because it was gpl before hotspot was gpl'd it was kept separate >> >>from >> >>>>>>>>the hotspot code. That should be fixed soon I'd guess. There was a >>>> >>>>note >>>> >>>> >>>>>>>>here >>>>>>>>http://c1.complang.tuwien.ac.at/pipermail/cacao/2006- >>>>>>> >>>>>>>November/000195.html >>>>>>> >>>>>>> >>>>>>> >>>>>>>>where someone hacked the cacao disassembler to get around this. The >>>>>>>>disassembler you build (.dll or .so) needs to go into the jvm (or >>>>>>>>somewhere in your LD_LIBRARY_PATH or equivalent) were it will get >>>>>>> >>>>>>>loaded. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>With the server version of hotspot there is another develop flag >>>>>>>>-XX:+PrintOptoAssembly which will print a very stylized version of >>>> >>>>the >>>> >>>> >>>>>>>>code the jit produces. It will do this without the disassembler >> >>being >> >>>>>>>>present. >>>>>>> >>>>>>>You can also use the "fastdebug" version of HotSpot to get >>>>>>>access to the -XX:+PrintAssembly flag. The fastdebug version >>>>>>>is built as part of the "make world" target. You still need >>>>>>>the dissassembler, as Steve says. >>>>>>> >>>>>>> ... peter >>>>>>> >>>>>>>-- >>>>>>>No virus found in this incoming message. >>>>>>>Checked by AVG Free Edition. >>>>>>>Version: 7.5.432 / Virus Database: 268.15.9/573 - Release Date: >>>>> >>>>>12/5/2006 >>>>> >>>>> >>>>>>>4:07 PM >>>>>>> >>>>>> >>>>>> >>>>>-- >>>>>No virus found in this incoming message. >>>>>Checked by AVG Free Edition. >>>>>Version: 7.5.432 / Virus Database: 268.15.15/579 - Release Date: >>>> >>>>12/7/2006 >>>> >>>> >>>>>1:31 PM >>>>> >>>> >>>>-- >>>>No virus found in this outgoing message. >>>>Checked by AVG Free Edition. >>>>Version: 7.5.432 / Virus Database: 268.16.12/628 - Release Date: >> >>1/15/2007 >> >>>>11:04 AM >>>> >>>> >>>>-- >>>>No virus found in this incoming message. >>>>Checked by AVG Free Edition. >>>>Version: 7.5.432 / Virus Database: 268.16.12/628 - Release Date: >> >>1/15/2007 >> >>>>11:04 AM >>>> >>> >>> >>-- >>No virus found in this incoming message. >>Checked by AVG Free Edition. >>Version: 7.5.446 / Virus Database: 269.4.0/762 - Release Date: 4/15/2007 >>4:22 PM >> > > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: 7/31/2007 > 5:26 PM > > From ted at tedneward.com Sat Aug 4 03:07:30 2007 From: ted at tedneward.com (Ted Neward) Date: Sat, 4 Aug 2007 03:07:30 -0700 Subject: Question In-Reply-To: <46B25CF4.2050805@Sun.COM> Message-ID: <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> I'm not a great resource for advice on how to distribute and package things in the open source world, but I'll certainly test whatever drops you make. :-) Meanwhile, speaking simply for what would be easiest from my position, it would be nice if you could instead, pull the GNU binutils bits necessary into the OpenJDK source repositories (SVN or Mercurial or whatever), then add your diffs and just merge in changes to binutils as they occur. (Frankly, I don't see that there'd be all that many changes you'd need to make, once the disassembler was in place, but maybe I'm shortsighted here.) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Chuck.Rasbold at Sun.COM [mailto:Chuck.Rasbold at Sun.COM] > Sent: Thursday, August 02, 2007 3:39 PM > To: Ted Neward > Cc: hotspot-compiler-dev at openjdk.dev.java.net > Subject: Re: Question > > Ted - > > In early July, Sun's legal department gave the OK to open source a > disassembler based on GNU binutils 2.17. Any delay in progress since > then is purely my own fault, as I have been attending to other > engineering duties. > > Based on advice I received so far, the plan is to start an OpenJDK > subproject, and distribute the disassembler as a set of diffs and > additions to the latest GNU binutils. To use with +PrintAssembly, one > would get binutils, apply the source patches, build using the supplied > makefile into a .dll or .so, and install the library into a known > location. > > Internally, I still need to do some cleanup and testing of the > disassembler...hopefully I haven't broken it moving it forward to > 2.17. > > Externally, I need to figure out how the OpenJDK process works, and > make sure the distribution and packaging method is reasonable. I am a > novice in the open source world, and recommendations from those more > experienced than me are welcome. > > -- Chuck > > Ted Neward wrote: > > Two questions: > > (*) Are we any further on this? > > (*) What about disassembly under Linux or Solaris? Anybody have good > > suggestions for a disassembler to use for -XX:+PrintAssembly? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > > > >>-----Original Message----- > >>From: Chuck.Rasbold at Sun.COM [mailto:Chuck.Rasbold at Sun.COM] > >>Sent: Tuesday, April 17, 2007 3:25 PM > >>To: Ted Neward > >>Cc: hotspot-compiler-dev at openjdk.dev.java.net > >>Subject: Re: Question > >> > >>I can't apologize enough on how long this is taking. We still working > on > >>it. > >> > >>-- Chuck > >> > >>Ted Neward wrote: > >> > >>>Any followup here? I'm still hoping to get the one that Sun uses, > rather > >>>than spend the energy/time/effort to write my own.... > >>> > >>>Ted Neward > >>>Java, .NET, XML Services > >>>Consulting, Teaching, Speaking, Writing > >>>http://www.tedneward.com > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Ted Neward [mailto:ted at tedneward.com] > >>>>Sent: Monday, January 15, 2007 4:30 PM > >>>>To: hotspot-compiler-dev at openjdk.dev.java.net > >>>>Subject: RE: Question > >>>> > >>>>Any word on getting this thing open-sourced? I know it's probably > >> > >>possible > >> > >>>>to build one for myself, but.... Oy. Would *much* rather not have to > do > >>>>that. > >>>> > >>>>Ted Neward > >>>>Java, .NET, XML Services > >>>>Consulting, Teaching, Speaking, Writing > >>>>http://www.tedneward.com > >>>> > >>>> > >>>> > >>>> > >>>>>-----Original Message----- > >>>>>From: Chuck.Rasbold at Sun.COM [mailto:Chuck.Rasbold at Sun.COM] > >>>>>Sent: Thursday, December 07, 2006 2:44 PM > >>>>>To: hotspot-compiler-dev at openjdk.dev.java.net > >>>>>Subject: Re: Question > >>>>> > >>>>>Sun has a disassembler which is based on the disassembler source code > >>>> > >>>>from > >>>> > >>>> > >>>>>a gdb > >>>>>of many years past. > >>>>> > >>>>>The disassembler is built into a .so or .dll. Typically, I place that > >>>>>disassembler.so file in the same directory as the libjvm.so of > >> > >>interest. > >> > >>>>>Other > >>>>>times, on Solaris, I will set my LD_LIBRARY_PATH to include the > >>>> > >>>>directory > >>>> > >>>> > >>>>>where > >>>>>the .so resides. I'm not much of a Windows guy, so I can't advise > you > >>>>>there. > >>>>> > >>>>>Until now, the disassembler source has been kept separate from the > >>>> > >>>>HotSpot > >>>> > >>>> > >>>>>source tree and the binary not distributed to customers in order to > >>>> > >>>>avoid > >>>> > >>>> > >>>>>the > >>>>>complications that would be incurred by Sun due to the GPL. > >>>>> > >>>>>Of course, the world is now different and due to an oversight, it was > >>>> > >>>>not > >>>> > >>>> > >>>>>included when HotSpot was open sourced. We're currently working on > >>>>>getting it > >>>>>distributed with HotSpot. > >>>>> > >>>>>Hopefully, I've made things a bit clearer. > >>>>> > >>>>>-- Chuck > >>>>> > >>>>>Ted Neward wrote: > >>>>> > >>>>> > >>>>>>So help me out here, if you don't mind--when you say I will "need > the > >>>>>>disassembler", you're saying I have to download (what?) and put it > >>>>> > >>>>>(where?)? > >>>>> > >>>>> > >>>>>>Unfortunately, the link you sent, Steve, doesn't say much beyond > that > >>>>> > >>>>>fact > >>>>> > >>>>> > >>>>>>that the poster hacked it--I'm not sure what to do with it once I > find > >>>>> > >>>>>it. > >>>>> > >>>>> > >>>>>>Can I grab the GNU disassembler and use it, since I'm not in the > same > >>>>> > >>>>>boat > >>>>> > >>>>> > >>>>>>as Sun re: licensning and distribution issues? > >>>>>> > >>>>>>Bear in mind, I want to do this under Windows if I can; I dunno if > >>>> > >>>>that > >>>> > >>>> > >>>>>>makes a difference. > >>>>>> > >>>>>>Sorry for being such the noob, but one hope I have is to sort > through > >>>>> > >>>>>all > >>>>> > >>>>> > >>>>>>this and put it into an article or paper or presentation and help > >>>> > >>>>others > >>>> > >>>> > >>>>>to > >>>>> > >>>>> > >>>>>>get into seeing all this stuff without having to wade through the > same > >>>>> > >>>>>steps > >>>>> > >>>>> > >>>>>>by hand. :-) > >>>>>> > >>>>>>Ted Neward > >>>>>>Java, .NET, XML Services > >>>>>>Consulting, Teaching, Speaking, Writing > >>>>>>http://www.tedneward.com > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>-----Original Message----- > >>>>>>>From: Peter.Kessler at Sun.COM [mailto:Peter.Kessler at Sun.COM] > >>>>>>>Sent: Tuesday, December 05, 2006 11:57 AM > >>>>>>>To: hotspot-compiler-dev at openjdk.dev.java.net > >>>>>>>Subject: Re: Question > >>>>>>> > >>>>>>>steve goldman wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Ted Neward wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>So one thing I?d like to see (via console output or some other > >>>>>>>>>out-of-band > >>>>>>>>>form of view) is the code generated by the JIT compiler when it > >> > >>JITs > >> > >>>>a > >>>> > >>>> > >>>>>>>>>method. What?s the best way for doing so? > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>>You need two things, a "develop" version of hotspot and the > >>>>>>>>disassembler. There is a flag -XX:+PrintAssembly which will > attempt > >>>> > >>>>to > >>>> > >>>> > >>>>>>>>dynamically load the disassembler and as various code blobs are > >>>>>>>>generated will invoke the disassembler. The product version of > >>>> > >>>>hotspot > >>>> > >>>> > >>>>>>>>doesn't enable this flag so you need to build a version that isn't > >>>> > >>>>the > >>>> > >>>> > >>>>>>>>product (or convert the switch from "develop" to "product"). In > any > >>>>> > >>>>>case > >>>>> > >>>>> > >>>>>>>>I think you'll have to build the jvm. Additionally you need the > >>>>>>>>disassembler. Unfortunately that got left out of the initial > source > >>>>>>>>release. The disassembler we use is based on the gnu disassembler > >> > >>and > >> > >>>>>>>>because it was gpl before hotspot was gpl'd it was kept separate > >> > >>from > >> > >>>>>>>>the hotspot code. That should be fixed soon I'd guess. There was a > >>>> > >>>>note > >>>> > >>>> > >>>>>>>>here > >>>>>>>>http://c1.complang.tuwien.ac.at/pipermail/cacao/2006- > >>>>>>> > >>>>>>>November/000195.html > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>where someone hacked the cacao disassembler to get around this. > The > >>>>>>>>disassembler you build (.dll or .so) needs to go into the jvm (or > >>>>>>>>somewhere in your LD_LIBRARY_PATH or equivalent) were it will get > >>>>>>> > >>>>>>>loaded. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>With the server version of hotspot there is another develop flag > >>>>>>>>-XX:+PrintOptoAssembly which will print a very stylized version of > >>>> > >>>>the > >>>> > >>>> > >>>>>>>>code the jit produces. It will do this without the disassembler > >> > >>being > >> > >>>>>>>>present. > >>>>>>> > >>>>>>>You can also use the "fastdebug" version of HotSpot to get > >>>>>>>access to the -XX:+PrintAssembly flag. The fastdebug version > >>>>>>>is built as part of the "make world" target. You still need > >>>>>>>the dissassembler, as Steve says. > >>>>>>> > >>>>>>> ... peter > >>>>>>> > >>>>>>>-- > >>>>>>>No virus found in this incoming message. > >>>>>>>Checked by AVG Free Edition. > >>>>>>>Version: 7.5.432 / Virus Database: 268.15.9/573 - Release Date: > >>>>> > >>>>>12/5/2006 > >>>>> > >>>>> > >>>>>>>4:07 PM > >>>>>>> > >>>>>> > >>>>>> > >>>>>-- > >>>>>No virus found in this incoming message. > >>>>>Checked by AVG Free Edition. > >>>>>Version: 7.5.432 / Virus Database: 268.15.15/579 - Release Date: > >>>> > >>>>12/7/2006 > >>>> > >>>> > >>>>>1:31 PM > >>>>> > >>>> > >>>>-- > >>>>No virus found in this outgoing message. > >>>>Checked by AVG Free Edition. > >>>>Version: 7.5.432 / Virus Database: 268.16.12/628 - Release Date: > >> > >>1/15/2007 > >> > >>>>11:04 AM > >>>> > >>>> > >>>>-- > >>>>No virus found in this incoming message. > >>>>Checked by AVG Free Edition. > >>>>Version: 7.5.432 / Virus Database: 268.16.12/628 - Release Date: > >> > >>1/15/2007 > >> > >>>>11:04 AM > >>>> > >>> > >>> > >>-- > >>No virus found in this incoming message. > >>Checked by AVG Free Edition. > >>Version: 7.5.446 / Virus Database: 269.4.0/762 - Release Date: 4/15/2007 > >>4:22 PM > >> > > > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: > 7/31/2007 > > 5:26 PM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.11.2/933 - Release Date: 8/2/2007 > 2:22 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.2/933 - Release Date: 8/2/2007 2:22 PM From ted at tedneward.com Tue Aug 7 18:57:37 2007 From: ted at tedneward.com (Ted Neward) Date: Tue, 7 Aug 2007 18:57:37 -0700 Subject: Question In-Reply-To: References: <46B25CF4.2050805@Sun.COM> <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> Message-ID: <006601c7d95f$8ed12460$ac736d20$@com> Lest there be any doubt, I'm in favor of a longer-term strategy, such as Volker's #2 option below, that both makes it easier for people to build the disassembler and for Sun (and later the OpenJDK community) to maintain the disassembler. Having said that, though, I'm also in favor of getting something into the build stream sooner rather than later, and if #1 is what's necessary to make that happen, then I'd see it as a step forward, even if (hopefully) it's only an interim step. Having said that, I've never built a disassembler, and I'm only marginally aware of what "building against the binutils" means. Can somebody give me some resources on what this would look like? (I'm curious not just from a "building one for Java" perspective, but also just a generalized "how does the whole thing work" perspective.) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Tuesday, August 07, 2007 10:24 AM > To: Ted Neward > Cc: Chuck.Rasbold at sun.com; hotspot-compiler-dev at openjdk.dev.java.net > Subject: Re: Question > > Hi Ted, Chuck, > > some time ago I compiled a disassembler library for our internal use. > Unfortunately it was build to work with the 1.5 JDK and contains some > minor changes to the original SUN interface, so it wouldn't help you > if I'd send it to you. > > But as a reaction to Chucks mail, I would strongly vote against the > proposed proceeding of releasing only diffs against the latest GNU > binutils. In my eys this would unneccesarily compilcate the build. And > in some years it would be hard to get this 'latest' version of the GNU > binutils. > > I see two alternatives: > > 1.) Quick and dirty: just incorporate a current version into OpenJDK. > Now that OpenJDK is GPL, this shouldn't be that much of a problem. > This approach isn't the cleanest from a software engineering point of > view because of the code duplication. But fortunately, the opcodes of > the CPUs won't change that much in the future, so I think, the problem > will be manageable. > > 2.) Silver bullet: why not doing it right and just depend on > 'libopcodes' from binutilities. This would need some minor hacking of > the interface to the disassembler, but it would solve all the problems > once and forever: support for virtually any architecture supported by > binutils, always up to date (as long as the user has an up to date > binutils installation) and no unnecessary code duplication. > > Any comments? > Regards, > Volker > > > On 8/4/07, Ted Neward wrote: > > I'm not a great resource for advice on how to distribute and package > things > > in the open source world, but I'll certainly test whatever drops you > make. > > :-) > > > > Meanwhile, speaking simply for what would be easiest from my > position, it > > would be nice if you could instead, pull the GNU binutils bits > necessary > > into the OpenJDK source repositories (SVN or Mercurial or whatever), > then > > add your diffs and just merge in changes to binutils as they occur. > > (Frankly, I don't see that there'd be all that many changes you'd > need to > > make, once the disassembler was in place, but maybe I'm shortsighted > here.) > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > > > -----Original Message----- > > > From: Chuck.Rasbold at Sun.COM [mailto:Chuck.Rasbold at Sun.COM] > > > Sent: Thursday, August 02, 2007 3:39 PM > > > To: Ted Neward > > > Cc: hotspot-compiler-dev at openjdk.dev.java.net > > > Subject: Re: Question > > > > > > Ted - > > > > > > In early July, Sun's legal department gave the OK to open source a > > > disassembler based on GNU binutils 2.17. Any delay in progress > since > > > then is purely my own fault, as I have been attending to other > > > engineering duties. > > > > > > Based on advice I received so far, the plan is to start an OpenJDK > > > subproject, and distribute the disassembler as a set of diffs and > > > additions to the latest GNU binutils. To use with +PrintAssembly, > one > > > would get binutils, apply the source patches, build using the > supplied > > > makefile into a .dll or .so, and install the library into a known > > > location. > > > > > > Internally, I still need to do some cleanup and testing of the > > > disassembler...hopefully I haven't broken it moving it forward to > > > 2.17. > > > > > > Externally, I need to figure out how the OpenJDK process works, and > > > make sure the distribution and packaging method is reasonable. I am > a > > > novice in the open source world, and recommendations from those > more > > > experienced than me are welcome. > > > > > > -- Chuck > > > > > > Ted Neward wrote: > > > > Two questions: > > > > (*) Are we any further on this? > > > > (*) What about disassembly under Linux or Solaris? Anybody have > good > > > > suggestions for a disassembler to use for -XX:+PrintAssembly? > > > > > > > > Ted Neward > > > > Java, .NET, XML Services > > > > Consulting, Teaching, Speaking, Writing > > > > http://www.tedneward.com > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: Chuck.Rasbold at Sun.COM [mailto:Chuck.Rasbold at Sun.COM] > > > >>Sent: Tuesday, April 17, 2007 3:25 PM > > > >>To: Ted Neward > > > >>Cc: hotspot-compiler-dev at openjdk.dev.java.net > > > >>Subject: Re: Question > > > >> > > > >>I can't apologize enough on how long this is taking. We still > working > > > on > > > >>it. > > > >> > > > >>-- Chuck > > > >> > > > >>Ted Neward wrote: > > > >> > > > >>>Any followup here? I'm still hoping to get the one that Sun > uses, > > > rather > > > >>>than spend the energy/time/effort to write my own.... > > > >>> > > > >>>Ted Neward > > > >>>Java, .NET, XML Services > > > >>>Consulting, Teaching, Speaking, Writing > > > >>>http://www.tedneward.com > > > >>> > > > >>> > > > >>> > > > >>>>-----Original Message----- > > > >>>>From: Ted Neward [mailto:ted at tedneward.com] > > > >>>>Sent: Monday, January 15, 2007 4:30 PM > > > >>>>To: hotspot-compiler-dev at openjdk.dev.java.net > > > >>>>Subject: RE: Question > > > >>>> > > > >>>>Any word on getting this thing open-sourced? I know it's > probably > > > >> > > > >>possible > > > >> > > > >>>>to build one for myself, but.... Oy. Would *much* rather not > have to > > > do > > > >>>>that. > > > >>>> > > > >>>>Ted Neward > > > >>>>Java, .NET, XML Services > > > >>>>Consulting, Teaching, Speaking, Writing > > > >>>>http://www.tedneward.com > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>>-----Original Message----- > > > >>>>>From: Chuck.Rasbold at Sun.COM [mailto:Chuck.Rasbold at Sun.COM] > > > >>>>>Sent: Thursday, December 07, 2006 2:44 PM > > > >>>>>To: hotspot-compiler-dev at openjdk.dev.java.net > > > >>>>>Subject: Re: Question > > > >>>>> > > > >>>>>Sun has a disassembler which is based on the disassembler > source code > > > >>>> > > > >>>>from > > > >>>> > > > >>>> > > > >>>>>a gdb > > > >>>>>of many years past. > > > >>>>> > > > >>>>>The disassembler is built into a .so or .dll. Typically, I > place that > > > >>>>>disassembler.so file in the same directory as the libjvm.so of > > > >> > > > >>interest. > > > >> > > > >>>>>Other > > > >>>>>times, on Solaris, I will set my LD_LIBRARY_PATH to include > the > > > >>>> > > > >>>>directory > > > >>>> > > > >>>> > > > >>>>>where > > > >>>>>the .so resides. I'm not much of a Windows guy, so I can't > advise > > > you > > > >>>>>there. > > > >>>>> > > > >>>>>Until now, the disassembler source has been kept separate from > the > > > >>>> > > > >>>>HotSpot > > > >>>> > > > >>>> > > > >>>>>source tree and the binary not distributed to customers in > order to > > > >>>> > > > >>>>avoid > > > >>>> > > > >>>> > > > >>>>>the > > > >>>>>complications that would be incurred by Sun due to the GPL. > > > >>>>> > > > >>>>>Of course, the world is now different and due to an oversight, > it was > > > >>>> > > > >>>>not > > > >>>> > > > >>>> > > > >>>>>included when HotSpot was open sourced. We're currently > working on > > > >>>>>getting it > > > >>>>>distributed with HotSpot. > > > >>>>> > > > >>>>>Hopefully, I've made things a bit clearer. > > > >>>>> > > > >>>>>-- Chuck > > > >>>>> > > > >>>>>Ted Neward wrote: > > > >>>>> > > > >>>>> > > > >>>>>>So help me out here, if you don't mind--when you say I will > "need > > > the > > > >>>>>>disassembler", you're saying I have to download (what?) and > put it > > > >>>>> > > > >>>>>(where?)? > > > >>>>> > > > >>>>> > > > >>>>>>Unfortunately, the link you sent, Steve, doesn't say much > beyond > > > that > > > >>>>> > > > >>>>>fact > > > >>>>> > > > >>>>> > > > >>>>>>that the poster hacked it--I'm not sure what to do with it > once I > > > find > > > >>>>> > > > >>>>>it. > > > >>>>> > > > >>>>> > > > >>>>>>Can I grab the GNU disassembler and use it, since I'm not in > the > > > same > > > >>>>> > > > >>>>>boat > > > >>>>> > > > >>>>> > > > >>>>>>as Sun re: licensning and distribution issues? > > > >>>>>> > > > >>>>>>Bear in mind, I want to do this under Windows if I can; I > dunno if > > > >>>> > > > >>>>that > > > >>>> > > > >>>> > > > >>>>>>makes a difference. > > > >>>>>> > > > >>>>>>Sorry for being such the noob, but one hope I have is to sort > > > through > > > >>>>> > > > >>>>>all > > > >>>>> > > > >>>>> > > > >>>>>>this and put it into an article or paper or presentation and > help > > > >>>> > > > >>>>others > > > >>>> > > > >>>> > > > >>>>>to > > > >>>>> > > > >>>>> > > > >>>>>>get into seeing all this stuff without having to wade through > the > > > same > > > >>>>> > > > >>>>>steps > > > >>>>> > > > >>>>> > > > >>>>>>by hand. :-) > > > >>>>>> > > > >>>>>>Ted Neward > > > >>>>>>Java, .NET, XML Services > > > >>>>>>Consulting, Teaching, Speaking, Writing > > > >>>>>>http://www.tedneward.com > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>>>-----Original Message----- > > > >>>>>>>From: Peter.Kessler at Sun.COM [mailto:Peter.Kessler at Sun.COM] > > > >>>>>>>Sent: Tuesday, December 05, 2006 11:57 AM > > > >>>>>>>To: hotspot-compiler-dev at openjdk.dev.java.net > > > >>>>>>>Subject: Re: Question > > > >>>>>>> > > > >>>>>>>steve goldman wrote: > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>Ted Neward wrote: > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>>>So one thing I'd like to see (via console output or some > other > > > >>>>>>>>>out-of-band > > > >>>>>>>>>form of view) is the code generated by the JIT compiler > when it > > > >> > > > >>JITs > > > >> > > > >>>>a > > > >>>> > > > >>>> > > > >>>>>>>>>method. What's the best way for doing so? > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>>>You need two things, a "develop" version of hotspot and the > > > >>>>>>>>disassembler. There is a flag -XX:+PrintAssembly which will > > > attempt > > > >>>> > > > >>>>to > > > >>>> > > > >>>> > > > >>>>>>>>dynamically load the disassembler and as various code blobs > are > > > >>>>>>>>generated will invoke the disassembler. The product version > of > > > >>>> > > > >>>>hotspot > > > >>>> > > > >>>> > > > >>>>>>>>doesn't enable this flag so you need to build a version > that isn't > > > >>>> > > > >>>>the > > > >>>> > > > >>>> > > > >>>>>>>>product (or convert the switch from "develop" to > "product"). In > > > any > > > >>>>> > > > >>>>>case > > > >>>>> > > > >>>>> > > > >>>>>>>>I think you'll have to build the jvm. Additionally you need > the > > > >>>>>>>>disassembler. Unfortunately that got left out of the > initial > > > source > > > >>>>>>>>release. The disassembler we use is based on the gnu > disassembler > > > >> > > > >>and > > > >> > > > >>>>>>>>because it was gpl before hotspot was gpl'd it was kept > separate > > > >> > > > >>from > > > >> > > > >>>>>>>>the hotspot code. That should be fixed soon I'd guess. > There was a > > > >>>> > > > >>>>note > > > >>>> > > > >>>> > > > >>>>>>>>here > > > >>>>>>>>http://c1.complang.tuwien.ac.at/pipermail/cacao/2006- > > > >>>>>>> > > > >>>>>>>November/000195.html > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>where someone hacked the cacao disassembler to get around > this. > > > The > > > >>>>>>>>disassembler you build (.dll or .so) needs to go into the > jvm (or > > > >>>>>>>>somewhere in your LD_LIBRARY_PATH or equivalent) were it > will get > > > >>>>>>> > > > >>>>>>>loaded. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>With the server version of hotspot there is another develop > flag > > > >>>>>>>>-XX:+PrintOptoAssembly which will print a very stylized > version of > > > >>>> > > > >>>>the > > > >>>> > > > >>>> > > > >>>>>>>>code the jit produces. It will do this without the > disassembler > > > >> > > > >>being > > > >> > > > >>>>>>>>present. > > > >>>>>>> > > > >>>>>>>You can also use the "fastdebug" version of HotSpot to get > > > >>>>>>>access to the -XX:+PrintAssembly flag. The fastdebug > version > > > >>>>>>>is built as part of the "make world" target. You still need > > > >>>>>>>the dissassembler, as Steve says. > > > >>>>>>> > > > >>>>>>> ... peter > > > >>>>>>> > > > >>>>>>>-- > > > >>>>>>>No virus found in this incoming message. > > > >>>>>>>Checked by AVG Free Edition. > > > >>>>>>>Version: 7.5.432 / Virus Database: 268.15.9/573 - Release > Date: > > > >>>>> > > > >>>>>12/5/2006 > > > >>>>> > > > >>>>> > > > >>>>>>>4:07 PM > > > >>>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>-- > > > >>>>>No virus found in this incoming message. > > > >>>>>Checked by AVG Free Edition. > > > >>>>>Version: 7.5.432 / Virus Database: 268.15.15/579 - Release > Date: > > > >>>> > > > >>>>12/7/2006 > > > >>>> > > > >>>> > > > >>>>>1:31 PM > > > >>>>> > > > >>>> > > > >>>>-- > > > >>>>No virus found in this outgoing message. > > > >>>>Checked by AVG Free Edition. > > > >>>>Version: 7.5.432 / Virus Database: 268.16.12/628 - Release > Date: > > > >> > > > >>1/15/2007 > > > >> > > > >>>>11:04 AM > > > >>>> > > > >>>> > > > >>>>-- > > > >>>>No virus found in this incoming message. > > > >>>>Checked by AVG Free Edition. > > > >>>>Version: 7.5.432 / Virus Database: 268.16.12/628 - Release > Date: > > > >> > > > >>1/15/2007 > > > >> > > > >>>>11:04 AM > > > >>>> > > > >>> > > > >>> > > > >>-- > > > >>No virus found in this incoming message. > > > >>Checked by AVG Free Edition. > > > >>Version: 7.5.446 / Virus Database: 269.4.0/762 - Release Date: > 4/15/2007 > > > >>4:22 PM > > > >> > > > > > > > > > > > > No virus found in this outgoing message. > > > > Checked by AVG Free Edition. > > > > Version: 7.5.476 / Virus Database: 269.11.0/929 - Release Date: > > > 7/31/2007 > > > > 5:26 PM > > > > > > > > > > > > > > No virus found in this incoming message. > > > Checked by AVG Free Edition. > > > Version: 7.5.476 / Virus Database: 269.11.2/933 - Release Date: > 8/2/2007 > > > 2:22 PM > > > > > > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.5.476 / Virus Database: 269.11.2/933 - Release Date: > 8/2/2007 > > 2:22 PM > > > > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date: > 8/6/2007 4:53 PM > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.11.8/940 - Release Date: 8/6/2007 4:53 PM From twisti at complang.tuwien.ac.at Wed Aug 8 11:59:43 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 08 Aug 2007 20:59:43 +0200 Subject: Question In-Reply-To: <006601c7d95f$8ed12460$ac736d20$@com> References: <46B25CF4.2050805@Sun.COM> <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> <006601c7d95f$8ed12460$ac736d20$@com> Message-ID: <1186599583.29156.1.camel@localhost.localdomain> On Tue, 2007-08-07 at 18:57 -0700, Ted Neward wrote: > Lest there be any doubt, I'm in favor of a longer-term strategy, such > as Volker's #2 option below, that both makes it easier for people to > build the disassembler and for Sun (and later the OpenJDK community) > to maintain the disassembler. Having said that, though, I'm also in > favor of getting something into the build stream sooner rather than > later, and if #1 is what's necessary to make that happen, then I'd see > it as a step forward, even if (hopefully) it's only an interim step. > > Having said that, I've never built a disassembler, and I'm only > marginally aware of what "building against the binutils" means. Can > somebody give me some resources on what this would look like? (I'm > curious not just from a "building one for Java" perspective, but also > just a generalized "how does the whole thing work" perspective.) It should not be that hard to link against binutils. We do that for CACAO since a long time and one of our developers got HotSpot working with a recent binutils version in November, IIRC 2 days after HotSpot was released. You can take a look at our code, it's very simple. - twisti From Peter.Kessler at Sun.COM Wed Aug 8 12:45:52 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 08 Aug 2007 12:45:52 -0700 Subject: Question In-Reply-To: <1186599583.29156.1.camel@localhost.localdomain> References: <46B25CF4.2050805@Sun.COM> <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> <006601c7d95f$8ed12460$ac736d20$@com> <1186599583.29156.1.camel@localhost.localdomain> Message-ID: <46BA1D70.2060107@Sun.COM> Christian Thalinger wrote: > On Tue, 2007-08-07 at 18:57 -0700, Ted Neward wrote: >> .... Could we move this thread from hotspot-compiler-dev at openjdk.dev.java.net to hotspot-compiler-dev at openjdk.java.net? The first list just forwards to the second list, but since you all are subscribed to the second list but not the first list, I have to approve all your postings to the first list. That means my lack of attention is just slowing you all down. I'm in the way to serve as a spam filter. (Part of garbage collection? :-) I assume most of you are just hitting "Reply-All" and so aren't even aware of the difference between openjdk.dev.java.net and openjdk.java.net. But you might also want to check your address books to see that new posts to hotspot-compiler-dev will go to openjdk.java.net. Thanks. ... peter From twisti at complang.tuwien.ac.at Wed Aug 8 13:17:35 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 08 Aug 2007 22:17:35 +0200 Subject: Question In-Reply-To: <46BA1D70.2060107@Sun.COM> References: <46B25CF4.2050805@Sun.COM> <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> <006601c7d95f$8ed12460$ac736d20$@com> <1186599583.29156.1.camel@localhost.localdomain> <46BA1D70.2060107@Sun.COM> Message-ID: <1186604255.29156.4.camel@localhost.localdomain> On Wed, 2007-08-08 at 12:45 -0700, Peter B. Kessler wrote: Hi Peter! > Could we move this thread from hotspot-compiler-dev at openjdk.dev.java.net > to hotspot-compiler-dev at openjdk.java.net? The first list just forwards > to the second list, but since you all are subscribed to the second list > but not the first list, I have to approve all your postings to the first > list. That means my lack of attention is just slowing you all down. > I'm in the way to serve as a spam filter. (Part of garbage collection? :-) Hehe :-) > > I assume most of you are just hitting "Reply-All" and so aren't even > aware of the difference between openjdk.dev.java.net and openjdk.java.net. > But you might also want to check your address books to see that new posts > to hotspot-compiler-dev will go to openjdk.java.net. OK. This list? - twisti From Peter.Kessler at Sun.COM Wed Aug 8 13:58:56 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Wed, 08 Aug 2007 13:58:56 -0700 Subject: Question In-Reply-To: <1186604255.29156.4.camel@localhost.localdomain> References: <46B25CF4.2050805@Sun.COM> <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> <006601c7d95f$8ed12460$ac736d20$@com> <1186599583.29156.1.camel@localhost.localdomain> <46BA1D70.2060107@Sun.COM> <1186604255.29156.4.camel@localhost.localdomain> Message-ID: <46BA2E90.4010105@Sun.COM> Christian Thalinger wrote: > On Wed, 2007-08-08 at 12:45 -0700, Peter B. Kessler wrote: > > Hi Peter! > >> Could we move this thread from hotspot-compiler-dev at openjdk.dev.java.net >> to hotspot-compiler-dev at openjdk.java.net? The first list just forwards >> to the second list, but since you all are subscribed to the second list >> but not the first list, I have to approve all your postings to the first >> list. That means my lack of attention is just slowing you all down. >> I'm in the way to serve as a spam filter. (Part of garbage collection? :-) > > Hehe :-) > >> I assume most of you are just hitting "Reply-All" and so aren't even >> aware of the difference between openjdk.dev.java.net and openjdk.java.net. >> But you might also want to check your address books to see that new posts >> to hotspot-compiler-dev will go to openjdk.java.net. > > OK. This list? > > - twisti Yes. Thanks. Now, what was the original topic? :-) ... peter From volker.simonis at gmail.com Thu Aug 9 10:36:51 2007 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 9 Aug 2007 19:36:51 +0200 Subject: Question In-Reply-To: <46BA2E90.4010105@Sun.COM> References: <46B25CF4.2050805@Sun.COM> <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> <006601c7d95f$8ed12460$ac736d20$@com> <1186599583.29156.1.camel@localhost.localdomain> <46BA1D70.2060107@Sun.COM> <1186604255.29156.4.camel@localhost.localdomain> <46BA2E90.4010105@Sun.COM> Message-ID: Hi Guys, time to go back to the original topic: here comes a 'disassembler_i486.cpp' that uses a vanilla 'libopcodes.so' how it comes with every binutils distribution. It can be used as a simple replacement for the current 'disassembler_i486.cpp'. The only requirements during compile time is 'dis-asm.h' which is also provided by the binutils package. Usually this should be availabel on Linux and should be no problem on Windows as well if you use Cygwin anyway (I tried only on Linux). After compiling the HotSpot with the new version of 'disassembler_i486.cpp' you should now be able to use the various print options like for example -XX:+PrintCompilation -XX:+PrintAssembly, -XX:+PrintInterpreter and get a nice assembly output of wht's going on under the hood. @chenjie: this should also work on MIPS as binutils support MIPS. Could you check? Maybe it can be helpfull for your porting project. Implementation details -------------------------- I specially kept the diff to the original file small, so you can easily see what the crucial changes are. If this should get into the official release, we can of course get rid of a few things like for example the class 'i486_env' and 'Disassembler::decode_instruction' that arn't needed anymore. For other architectures, all that has to be done, is adapt the following lines in 'init_disassemble_info()': // Platform dependent stuff (i486) di.bytes_per_line = 0; di.endian = (bfd_endian) 1; di.mach = bfd_mach_i386_i8086; di.disassembler_options = (char *) "i386,suffix"; and choose the right name for the disassembler function in 'Disassembler::load_library()': hpi::dll_lookup(_library, "print_insn_i386"); The specific names for other architectures can be found in 'dis-asm.h'. Pitfalls -------- On my Suse Linux 10 I had a broken 'libopcodes.so' ("nm /usr/lib/libopcodes.so" returned no symbols. But building a new version of binutils is quite tricky too, because you HAVE to give ./configure the "--enable-64-bit-bfd" option (even on 32bit Linux), otherwise the resulting 'libopcodes.so' wont work! Heres my configure line for building binutils 2.17: ./configure --enable-shared --enable-64-bit-bfd Afterwards, just copy opcodes/.libs/libopcodes-2.17.so to /usr/lib and let /usr/lib/libopcodes.so link to it. That's it. Regards, Volker On 8/8/07, Peter B. Kessler wrote: > Christian Thalinger wrote: > > > On Wed, 2007-08-08 at 12:45 -0700, Peter B. Kessler wrote: > > > > Hi Peter! > > > >> Could we move this thread from hotspot-compiler-dev at openjdk.dev.java.net > >> to hotspot-compiler-dev at openjdk.java.net? The first list just forwards > >> to the second list, but since you all are subscribed to the second list > >> but not the first list, I have to approve all your postings to the first > >> list. That means my lack of attention is just slowing you all down. > >> I'm in the way to serve as a spam filter. (Part of garbage collection? :-) > > > > Hehe :-) > > > >> I assume most of you are just hitting "Reply-All" and so aren't even > >> aware of the difference between openjdk.dev.java.net and openjdk.java.net. > >> But you might also want to check your address books to see that new posts > >> to hotspot-compiler-dev will go to openjdk.java.net. > > > > OK. This list? > > > > - twisti > > > Yes. Thanks. Now, what was the original topic? :-) > > ... peter > -------------- next part -------------- A non-text attachment was scrubbed... Name: disassembler_i486.cpp Type: text/x-c++src Size: 8125 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20070809/b038ff1f/attachment.bin From chenj at lemote.com Thu Aug 9 19:50:14 2007 From: chenj at lemote.com (chenjie) Date: Fri, 10 Aug 2007 10:50:14 +0800 Subject: Question In-Reply-To: References: <46B25CF4.2050805@Sun.COM> <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> <006601c7d95f$8ed12460$ac736d20$@com> <1186599583.29156.1.camel@localhost.localdomain> <46BA1D70.2060107@Sun.COM> <1186604255.29156.4.camel@localhost.localdomain> <46BA2E90.4010105@Sun.COM> Message-ID: <46BBD266.1080207@lemote.com> Thank Volker for the message, actually, It is quit easy for MIPS to disassemble, because its instruction are fixed length, We have implemented a simple disassembler for JVM last year. Volker Simonis ????: > Hi Guys, > > time to go back to the original topic: > > here comes a 'disassembler_i486.cpp' that uses a vanilla > 'libopcodes.so' how it comes with every binutils distribution. It can > be used as a simple replacement for the current > 'disassembler_i486.cpp'. The only requirements during compile time is > 'dis-asm.h' which is also provided by the binutils package. Usually > this should be availabel on Linux and should be no problem on Windows > as well if you use Cygwin anyway (I tried only on Linux). > > After compiling the HotSpot with the new version of > 'disassembler_i486.cpp' you should now be able to use the various > print options like for example -XX:+PrintCompilation > -XX:+PrintAssembly, -XX:+PrintInterpreter and get a nice assembly > output of wht's going on under the hood. > > @chenjie: this should also work on MIPS as binutils support MIPS. > Could you check? Maybe it can be helpfull for your porting project. > > Implementation details > -------------------------- > I specially kept the diff to the original file small, so you can > easily see what the crucial changes are. If this should get into the > official release, we can of course get rid of a few things like for > example the class 'i486_env' and 'Disassembler::decode_instruction' > that arn't needed anymore. > > For other architectures, all that has to be done, is adapt the > following lines in 'init_disassemble_info()': > > // Platform dependent stuff (i486) > di.bytes_per_line = 0; > di.endian = (bfd_endian) 1; > di.mach = bfd_mach_i386_i8086; > di.disassembler_options = (char *) "i386,suffix"; > > and choose the right name for the disassembler function in > 'Disassembler::load_library()': > > hpi::dll_lookup(_library, "print_insn_i386"); > > The specific names for other architectures can be found in 'dis-asm.h'. > > Pitfalls > -------- > On my Suse Linux 10 I had a broken 'libopcodes.so' ("nm > /usr/lib/libopcodes.so" returned no symbols. But building a new > version of binutils is quite tricky too, because you HAVE to give > ./configure the "--enable-64-bit-bfd" option (even on 32bit Linux), > otherwise the resulting 'libopcodes.so' wont work! Heres my configure > line for building binutils 2.17: > > ./configure --enable-shared --enable-64-bit-bfd > > Afterwards, just copy opcodes/.libs/libopcodes-2.17.so to /usr/lib and > let /usr/lib/libopcodes.so link to it. That's it. > > Regards, > Volker > > On 8/8/07, Peter B. Kessler wrote: > >> Christian Thalinger wrote: >> >> >>> On Wed, 2007-08-08 at 12:45 -0700, Peter B. Kessler wrote: >>> >>> Hi Peter! >>> >>> >>>> Could we move this thread from hotspot-compiler-dev at openjdk.dev.java.net >>>> to hotspot-compiler-dev at openjdk.java.net? The first list just forwards >>>> to the second list, but since you all are subscribed to the second list >>>> but not the first list, I have to approve all your postings to the first >>>> list. That means my lack of attention is just slowing you all down. >>>> I'm in the way to serve as a spam filter. (Part of garbage collection? :-) >>>> >>> Hehe :-) >>> >>> >>>> I assume most of you are just hitting "Reply-All" and so aren't even >>>> aware of the difference between openjdk.dev.java.net and openjdk.java.net. >>>> But you might also want to check your address books to see that new posts >>>> to hotspot-compiler-dev will go to openjdk.java.net. >>>> >>> OK. This list? >>> >>> - twisti >>> >> Yes. Thanks. Now, what was the original topic? :-) >> >> ... peter >> >> >> ------------------------------------------------------------------------ >> >> #ifdef USE_PRAGMA_IDENT_SRC >> #pragma ident "@(#)disassembler_i486.cpp 1.47 07/05/05 17:04:14 JVM" >> #endif >> /* >> * Copyright 1997-2007 Sun Microsystems, Inc. All Rights Reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> * under the terms of the GNU General Public License version 2 only, as >> * published by the Free Software Foundation. >> * >> * This code is distributed in the hope that it will be useful, but WITHOUT >> * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> * version 2 for more details (a copy is included in the LICENSE file that >> * accompanied this code). >> * >> * You should have received a copy of the GNU General Public License version >> * 2 along with this work; if not, write to the Free Software Foundation, >> * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> * >> * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, >> * CA 95054 USA or visit www.sun.com if you need additional information or >> * have any questions. >> * >> */ >> >> # include "incls/_precompiled.incl" >> # include "incls/_disassembler_i486.cpp.incl" >> >> #ifndef PRODUCT >> >> #include >> >> void* Disassembler::_library = NULL; >> Disassembler::decode_func Disassembler::_decode_instruction = NULL; >> disassembler_ftype _decode_instruction = NULL; >> >> // Callback function that will be called by libopcodes to print >> // disassembled code ('fprintf_func' member of 'disassemble_info'). >> extern "C" int fprint_func(void *stream, const char* format, ...) { >> outputStream* st = reinterpret_cast(stream); >> va_list ap; >> va_start(ap, format); >> st->vprint(format, ap); >> va_end(ap); >> } >> >> // Callback function that will be called by libopcodes to read the >> // bytes to disassemble ('read_memory_func' member of 'disassemble_info'). >> extern "C" int read_memory_func(bfd_vma memaddr, bfd_byte *myaddr, >> unsigned int length, disassemble_info *info) { >> char* from = reinterpret_cast(memaddr); >> char* to = (char*)myaddr; >> >> while (length-- != 0) { >> *to++ = *from++; >> } >> return (0); >> } >> >> // Callback function that will be called by libopcodes to print >> // addresses ('print_address_func' member of 'disassemble_info'). >> extern "C" void print_address_func( bfd_vma addr, disassemble_info *info) { >> outputStream* st = reinterpret_cast(info->stream); >> st->print("0x%x", addr); >> } >> >> // Initialize a 'disassemble_info' structure for further calls to >> // the libopcodes decode function. >> static void init_disassemble_info(disassemble_info &di, const outputStream *st) { >> // Platform dependent stuff (i486) >> di.bytes_per_line = 0; >> di.endian = (bfd_endian) 1; >> di.mach = bfd_mach_i386_i8086; >> di.disassembler_options = (char *) "i386,suffix"; >> // Shared stuff that will be equal for all platforms >> di.stream = (void*)st; >> di.fprintf_func = fprint_func; >> di.read_memory_func = read_memory_func; >> di.print_address_func = print_address_func; >> } >> >> bool Disassembler::load_library() { >> if (_library == NULL) { >> char buf[1024]; >> char ebuf[1024]; >> sprintf(buf, "libopcodes%s", os::dll_file_extension()); >> _library = hpi::dll_load(buf, ebuf, sizeof ebuf); >> if (_library != NULL) { >> tty->print_cr("Loaded disassembler"); >> ::_decode_instruction = (disassembler_ftype) >> hpi::dll_lookup(_library, "print_insn_i386"); >> } >> } >> return (_library != NULL) && (::_decode_instruction != NULL); >> } >> >> class i486_env : public DisassemblerEnv { >> private: >> nmethod* code; >> outputStream* output; >> public: >> i486_env(nmethod* rcode, outputStream* routput) { >> code = rcode; >> output = routput; >> } >> void print_label(intptr_t value); >> void print_raw(char* str) { output->print_raw(str); } >> void print(char* format, ...); >> char* string_for_offset(intptr_t value); >> char* string_for_constant(unsigned char* pc, intptr_t value, int is_decimal); >> }; >> >> >> void i486_env::print_label(intptr_t value) { >> if (!Universe::is_fully_initialized()) { >> output->print(INTPTR_FORMAT, value); >> return; >> } >> address adr = (address) value; >> if (StubRoutines::contains(adr)) { >> StubCodeDesc* desc = StubCodeDesc::desc_for(adr); >> const char * desc_name = "unknown stub"; >> if (desc != NULL) { >> desc_name = desc->name(); >> } >> output->print("Stub::%s", desc_name); >> if (WizardMode) output->print(" " INTPTR_FORMAT, value); >> } else { >> output->print(INTPTR_FORMAT, value); >> } >> } >> >> void i486_env::print(char* format, ...) { >> va_list ap; >> va_start(ap, format); >> output->vprint(format, ap); >> va_end(ap); >> } >> >> char* i486_env::string_for_offset(intptr_t value) { >> stringStream st; >> if (!Universe::is_fully_initialized()) { >> st.print("%d", value); >> return st.as_string(); >> } >> BarrierSet* bs = Universe::heap()->barrier_set(); >> BarrierSet::Name bsn = bs->kind(); >> if (bs->kind() == BarrierSet::CardTableModRef && >> (jbyte*) value == ((CardTableModRefBS*)(bs))->byte_map_base) { >> st.print("word_map_base"); >> } else { >> st.print("%d", value); >> } >> return st.as_string(); >> } >> >> char* i486_env::string_for_constant(unsigned char* pc, intptr_t value, int is_decimal) { >> stringStream st; >> oop obj = NULL; >> if (code && ((obj = code->embeddedOop_at(pc)) != NULL)) { >> obj->print_value_on(&st); >> } else { >> if (is_decimal == 1) { >> st.print("%d", value); >> } else { >> st.print("0x%lx", value); >> } >> } >> return st.as_string(); >> } >> >> >> >> address Disassembler::decode_instruction(address start, DisassemblerEnv* env) { >> return ((decode_func) _decode_instruction)(start, env); >> } >> >> >> void Disassembler::decode(CodeBlob* cb, outputStream* st) { >> st = st ? st : tty; >> st->print_cr("Decoding CodeBlob " INTPTR_FORMAT, cb); >> decode(cb->instructions_begin(), cb->instructions_end(), st); >> } >> >> >> void Disassembler::decode(u_char* begin, u_char* end, outputStream* st) { >> st = st ? st : tty; >> >> const int show_bytes = false; // for disassembler debugging >> >> if (!load_library()) { >> st->print_cr("Could not load disassembler"); >> return; >> } >> >> disassemble_info di; >> init_disassemble_info(di, st); >> unsigned char* p = (unsigned char*) begin; >> CodeBlob* cb = CodeCache::find_blob_unsafe(begin); >> while (p < (unsigned char*) end) { >> if (cb != NULL) { >> cb->print_block_comment(st, (intptr_t)(p - cb->instructions_begin())); >> } >> >> unsigned char* p0 = p; >> st->print(" " INTPTR_FORMAT ": ", p); >> p += ::_decode_instruction(reinterpret_cast(p), &di); >> if (show_bytes) { >> st->print("\t\t\t"); >> while (p0 < p) st->print("%x ", *p0++); >> } >> st->cr(); >> } >> } >> >> >> void Disassembler::decode(nmethod* nm, outputStream* st) { >> st = st ? st : tty; >> >> st->print_cr("Decoding compiled method " INTPTR_FORMAT ":", nm); >> st->print("Code:"); >> st->cr(); >> >> if (!load_library()) { >> st->print_cr("Could not load disassembler"); >> return; >> } >> disassemble_info di; >> init_disassemble_info(di, st); >> >> unsigned char* p = nm->instructions_begin(); >> unsigned char* end = nm->instructions_end(); >> while (p < end) { >> if (p == nm->entry_point()) st->print_cr("[Entry Point]"); >> if (p == nm->verified_entry_point()) st->print_cr("[Verified Entry Point]"); >> if (p == nm->exception_begin()) st->print_cr("[Exception Handler]"); >> if (p == nm->stub_begin()) st->print_cr("[Stub Code]"); >> if (p == nm->consts_begin()) st->print_cr("[Constants]"); >> nm->print_block_comment(st, (intptr_t)(p - nm->instructions_begin())); >> unsigned char* p0 = p; >> st->print(" " INTPTR_FORMAT ": ", p); >> p += ::_decode_instruction(reinterpret_cast(p), &di); >> nm->print_code_comment_on(st, 40, p0, p); >> st->cr(); >> // Output pc bucket ticks if we have any >> address bucket_pc = FlatProfiler::bucket_start_for(p); >> if (bucket_pc != NULL && bucket_pc > p0 && bucket_pc <= p) { >> int bucket_count = FlatProfiler::bucket_count_for(bucket_pc); >> tty->print_cr("[%d]", bucket_count); >> } >> } >> } >> >> #endif // PRODUCT >> >> From Chuck.Rasbold at Sun.COM Mon Aug 13 13:04:06 2007 From: Chuck.Rasbold at Sun.COM (Chuck Rasbold) Date: Mon, 13 Aug 2007 13:04:06 -0700 Subject: Question In-Reply-To: References: <46B25CF4.2050805@Sun.COM> <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> <006601c7d95f$8ed12460$ac736d20$@com> <1186599583.29156.1.camel@localhost.localdomain> <46BA1D70.2060107@Sun.COM> <1186604255.29156.4.camel@localhost.localdomain> <46BA2E90.4010105@Sun.COM> Message-ID: <46C0B936.80000@Sun.COM> Volker - As an engineer, I like your proposal using libopcodes (option #2), but requiring the inclusion of 'dis-asm.h' (and other binutils headers) at compile time is probably a non-starter for Sun. Many of our partners use Solaris and would prefer to avoid GNU code altogether, as they have done for years. Similarly, directly incorporating a version of the disassembler (option #1) doesn't work either, as some of our partners do not want not to be bound by GPL at all. And, of course, the binutils code can not be contributed back to Sun. I'm exploring variations of option #2, hoping to find some workable solution. -- Chuck Rasbold Volker Simonis wrote: > Hi Guys, > > time to go back to the original topic: > > here comes a 'disassembler_i486.cpp' that uses a vanilla > 'libopcodes.so' how it comes with every binutils distribution. It can > be used as a simple replacement for the current > 'disassembler_i486.cpp'. The only requirements during compile time is > 'dis-asm.h' which is also provided by the binutils package. Usually > this should be availabel on Linux and should be no problem on Windows > as well if you use Cygwin anyway (I tried only on Linux). > > After compiling the HotSpot with the new version of > 'disassembler_i486.cpp' you should now be able to use the various > print options like for example -XX:+PrintCompilation > -XX:+PrintAssembly, -XX:+PrintInterpreter and get a nice assembly > output of wht's going on under the hood. > > @chenjie: this should also work on MIPS as binutils support MIPS. > Could you check? Maybe it can be helpfull for your porting project. > > Implementation details > -------------------------- > I specially kept the diff to the original file small, so you can > easily see what the crucial changes are. If this should get into the > official release, we can of course get rid of a few things like for > example the class 'i486_env' and 'Disassembler::decode_instruction' > that arn't needed anymore. > > For other architectures, all that has to be done, is adapt the > following lines in 'init_disassemble_info()': > > // Platform dependent stuff (i486) > di.bytes_per_line = 0; > di.endian = (bfd_endian) 1; > di.mach = bfd_mach_i386_i8086; > di.disassembler_options = (char *) "i386,suffix"; > > and choose the right name for the disassembler function in > 'Disassembler::load_library()': > > hpi::dll_lookup(_library, "print_insn_i386"); > > The specific names for other architectures can be found in 'dis-asm.h'. > > Pitfalls > -------- > On my Suse Linux 10 I had a broken 'libopcodes.so' ("nm > /usr/lib/libopcodes.so" returned no symbols. But building a new > version of binutils is quite tricky too, because you HAVE to give > ./configure the "--enable-64-bit-bfd" option (even on 32bit Linux), > otherwise the resulting 'libopcodes.so' wont work! Heres my configure > line for building binutils 2.17: > > ./configure --enable-shared --enable-64-bit-bfd > > Afterwards, just copy opcodes/.libs/libopcodes-2.17.so to /usr/lib and > let /usr/lib/libopcodes.so link to it. That's it. > > Regards, > Volker > > On 8/8/07, Peter B. Kessler wrote: > >>Christian Thalinger wrote: >> >> >>>On Wed, 2007-08-08 at 12:45 -0700, Peter B. Kessler wrote: >>> >>>Hi Peter! >>> >>> >>>>Could we move this thread from hotspot-compiler-dev at openjdk.dev.java.net >>>>to hotspot-compiler-dev at openjdk.java.net? The first list just forwards >>>>to the second list, but since you all are subscribed to the second list >>>>but not the first list, I have to approve all your postings to the first >>>>list. That means my lack of attention is just slowing you all down. >>>>I'm in the way to serve as a spam filter. (Part of garbage collection? :-) >>> >>>Hehe :-) >>> >>> >>>>I assume most of you are just hitting "Reply-All" and so aren't even >>>>aware of the difference between openjdk.dev.java.net and openjdk.java.net. >>>>But you might also want to check your address books to see that new posts >>>>to hotspot-compiler-dev will go to openjdk.java.net. >>> >>>OK. This list? >>> >>>- twisti >> >> >>Yes. Thanks. Now, what was the original topic? :-) >> >> ... peter >> >> From volker.simonis at gmail.com Mon Aug 13 15:30:36 2007 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Aug 2007 00:30:36 +0200 Subject: Question In-Reply-To: <46C0B936.80000@Sun.COM> References: <46B25CF4.2050805@Sun.COM> <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> <006601c7d95f$8ed12460$ac736d20$@com> <1186599583.29156.1.camel@localhost.localdomain> <46BA1D70.2060107@Sun.COM> <1186604255.29156.4.camel@localhost.localdomain> <46BA2E90.4010105@Sun.COM> <46C0B936.80000@Sun.COM> Message-ID: Hi Chuck, I'm happy that you agree from a technical point of view. And I can't really understand your 'political' arguments. I'm working for one of "your partners" (a Java licencesee) and I know for sure that we didn't got the disassembler at all because it isn't shipped to partners, it is used only internally within Sun. It needed quit an amount of emails and negotiations to finally get some diffs against an archaeological version of the binutilitis (which are GPL of course) so we could finally figure out how to build the disassembler. My proposal was related to OpenJDK and there should be no licence problems for OpenJDK. And with respect to your partners, pointing them to the OpenJDK implementation of the disassembler would be probably more usefull for them than receive some diffs against a software that is GPL anyway.So this shouldn't make the situation worse. There's another point here: the disassembler is only used in the debug version, which shouldn't be shipped to customers anyway, and using a software, even if it's GPLed, should be ok for in-house usage, as far as I understand the GPL. I can understand that you want to avoid the direct dependency on 'dis-asm.h'. That was probably the main reason, why the initial SUN disassembler chose to extend the binutils disassembler in order to avoid including GPLed interfaces into the JDK. As far as I can see, with my proposal it should be possible to avoid including 'dis-asm.h' if only you could define a structure similiar to "disassemble_info" in the VM. All ather parameters passed between the VM and the disassembler are merely funtion pointers and addresses. So my proposal would be: 1. Put all the binutils/libopcode dependent stuff (merely the definition of the "disassemble_info" structure and some funtion pointers into an extra file, say "disassemblerEnv.hpp" in OpenJDK.) 2. In the Sun JDK code, the same file could contain empty stubs, just to let the VM compile. 3. If somebody needs/wants the disassembler, he could just replace the stub-file from the Sun JDK with the one from OpenJDK. This shouldn't change anything for the current Sun version of the JDK, which for itself is not funtional with respect to the disassembler anyway. But it should make it easier, even for your licencesss, to use the disassembler, if they want to. With best regards, Volker On 8/13/07, Chuck Rasbold wrote: > Volker - > > As an engineer, I like your proposal using libopcodes (option #2), but > requiring the inclusion of 'dis-asm.h' (and other binutils headers) at > compile time is probably a non-starter for Sun. Many of our partners > use Solaris and would prefer to avoid GNU code altogether, as they > have done for years. > > Similarly, directly incorporating a version of the disassembler > (option #1) doesn't work either, as some of our partners do not want > not to be bound by GPL at all. And, of course, the binutils code can > not be contributed back to Sun. > > I'm exploring variations of option #2, hoping to find some workable > solution. > > -- Chuck Rasbold > > Volker Simonis wrote: > > Hi Guys, > > > > time to go back to the original topic: > > > > here comes a 'disassembler_i486.cpp' that uses a vanilla > > 'libopcodes.so' how it comes with every binutils distribution. It can > > be used as a simple replacement for the current > > 'disassembler_i486.cpp'. The only requirements during compile time is > > 'dis-asm.h' which is also provided by the binutils package. Usually > > this should be availabel on Linux and should be no problem on Windows > > as well if you use Cygwin anyway (I tried only on Linux). > > > > After compiling the HotSpot with the new version of > > 'disassembler_i486.cpp' you should now be able to use the various > > print options like for example -XX:+PrintCompilation > > -XX:+PrintAssembly, -XX:+PrintInterpreter and get a nice assembly > > output of wht's going on under the hood. > > > > @chenjie: this should also work on MIPS as binutils support MIPS. > > Could you check? Maybe it can be helpfull for your porting project. > > > > Implementation details > > -------------------------- > > I specially kept the diff to the original file small, so you can > > easily see what the crucial changes are. If this should get into the > > official release, we can of course get rid of a few things like for > > example the class 'i486_env' and 'Disassembler::decode_instruction' > > that arn't needed anymore. > > > > For other architectures, all that has to be done, is adapt the > > following lines in 'init_disassemble_info()': > > > > // Platform dependent stuff (i486) > > di.bytes_per_line = 0; > > di.endian = (bfd_endian) 1; > > di.mach = bfd_mach_i386_i8086; > > di.disassembler_options = (char *) "i386,suffix"; > > > > and choose the right name for the disassembler function in > > 'Disassembler::load_library()': > > > > hpi::dll_lookup(_library, "print_insn_i386"); > > > > The specific names for other architectures can be found in 'dis-asm.h'. > > > > Pitfalls > > -------- > > On my Suse Linux 10 I had a broken 'libopcodes.so' ("nm > > /usr/lib/libopcodes.so" returned no symbols. But building a new > > version of binutils is quite tricky too, because you HAVE to give > > ./configure the "--enable-64-bit-bfd" option (even on 32bit Linux), > > otherwise the resulting 'libopcodes.so' wont work! Heres my configure > > line for building binutils 2.17: > > > > ./configure --enable-shared --enable-64-bit-bfd > > > > Afterwards, just copy opcodes/.libs/libopcodes-2.17.so to /usr/lib and > > let /usr/lib/libopcodes.so link to it. That's it. > > > > Regards, > > Volker > > > > On 8/8/07, Peter B. Kessler wrote: > > > >>Christian Thalinger wrote: > >> > >> > >>>On Wed, 2007-08-08 at 12:45 -0700, Peter B. Kessler wrote: > >>> > >>>Hi Peter! > >>> > >>> > >>>>Could we move this thread from hotspot-compiler-dev at openjdk.dev.java.net > >>>>to hotspot-compiler-dev at openjdk.java.net? The first list just forwards > >>>>to the second list, but since you all are subscribed to the second list > >>>>but not the first list, I have to approve all your postings to the first > >>>>list. That means my lack of attention is just slowing you all down. > >>>>I'm in the way to serve as a spam filter. (Part of garbage collection? :-) > >>> > >>>Hehe :-) > >>> > >>> > >>>>I assume most of you are just hitting "Reply-All" and so aren't even > >>>>aware of the difference between openjdk.dev.java.net and openjdk.java.net. > >>>>But you might also want to check your address books to see that new posts > >>>>to hotspot-compiler-dev will go to openjdk.java.net. > >>> > >>>OK. This list? > >>> > >>>- twisti > >> > >> > >>Yes. Thanks. Now, what was the original topic? :-) > >> > >> ... peter > >> > >> > From Chuck.Rasbold at Sun.COM Thu Aug 16 09:25:44 2007 From: Chuck.Rasbold at Sun.COM (Chuck Rasbold) Date: Thu, 16 Aug 2007 09:25:44 -0700 Subject: Question In-Reply-To: References: <46B25CF4.2050805@Sun.COM> <09fc01c7d67f$48ee5cc0$802ca8c0@XPWork> <006601c7d95f$8ed12460$ac736d20$@com> <1186599583.29156.1.camel@localhost.localdomain> <46BA1D70.2060107@Sun.COM> <1186604255.29156.4.camel@localhost.localdomain> <46BA2E90.4010105@Sun.COM> <46C0B936.80000@Sun.COM> Message-ID: <46C47A88.2080002@Sun.COM> Volker - Thank you for your endorsement of the current disassembler. Seriously though, I appreciate your input and I agree with your assessment: it is based on an ancient binutils, it is non-obvious to build, and it is generally available to nobody outside of Sun. I think we both have the same goal. That is, to provide a binutils based disassembler for HotSpot available as an open source. We want it to be available to both licensees and as well as open source collaborators. My initial plan was to clean up (to some degree) the internal diassembler and base it on the less-than-ancient binutils. The preference inside Sun was to provide this as an OpenJDK project. It was felt that the quickest way to this end was to provide diffs against binutils 2.17 and a makefile...essentially a slightly polished version that you've seen in your role working for a Java licensee. I think your libopcodes proposal is a superior one to my original plan. I will pursue it in the amount of time that I have available to give to the disassembler. If you have already done a concrete implementation, you can help if you are able to send it back to Sun, so it can be put in the "official" OpenJDK. Of course, to do so, you either have to sign an SCA, or have your employer send the changes back as a licensee. My apologies for stumbling my way through this process. I'm figuring it out as I go. -- Chuck Volker Simonis wrote: > Hi Chuck, > > I'm happy that you agree from a technical point of view. And I can't > really understand your 'political' arguments. I'm working for one of > "your partners" (a Java licencesee) and I know for sure that we didn't > got the disassembler at all because it isn't shipped to partners, it > is used only internally within Sun. It needed quit an amount of emails > and negotiations to finally get some diffs against an archaeological > version of the binutilitis (which are GPL of course) so we could > finally figure out how to build the disassembler. > > My proposal was related to OpenJDK and there should be no licence > problems for OpenJDK. And with respect to your partners, pointing them > to the OpenJDK implementation of the disassembler would be probably > more usefull for them than receive some diffs against a software that > is GPL anyway.So this shouldn't make the situation worse. > > There's another point here: the disassembler is only used in the debug > version, which shouldn't be shipped to customers anyway, and using a > software, even if it's GPLed, should be ok for in-house usage, as far > as I understand the GPL. > > I can understand that you want to avoid the direct dependency on > 'dis-asm.h'. That was probably the main reason, why the initial SUN > disassembler chose to extend the binutils disassembler in order to > avoid including GPLed interfaces into the JDK. As far as I can see, > with my proposal it should be possible to avoid including 'dis-asm.h' > if only you could define a structure similiar to "disassemble_info" in > the VM. All ather parameters passed between the VM and the > disassembler are merely funtion pointers and addresses. > > So my proposal would be: > > 1. Put all the binutils/libopcode dependent stuff (merely the > definition of the "disassemble_info" structure and some funtion > pointers into an extra file, say "disassemblerEnv.hpp" in OpenJDK.) > 2. In the Sun JDK code, the same file could contain empty stubs, just > to let the VM compile. > 3. If somebody needs/wants the disassembler, he could just replace the > stub-file from the Sun JDK with the one from OpenJDK. > > This shouldn't change anything for the current Sun version of the JDK, > which for itself is not funtional with respect to the disassembler > anyway. But it should make it easier, even for your licencesss, to use > the disassembler, if they want to. > > With best regards, > Volker > > > > On 8/13/07, Chuck Rasbold wrote: > >>Volker - >> >>As an engineer, I like your proposal using libopcodes (option #2), but >>requiring the inclusion of 'dis-asm.h' (and other binutils headers) at >>compile time is probably a non-starter for Sun. Many of our partners >>use Solaris and would prefer to avoid GNU code altogether, as they >>have done for years. >> >>Similarly, directly incorporating a version of the disassembler >>(option #1) doesn't work either, as some of our partners do not want >>not to be bound by GPL at all. And, of course, the binutils code can >>not be contributed back to Sun. >> >>I'm exploring variations of option #2, hoping to find some workable >>solution. >> >>-- Chuck Rasbold >> >>Volker Simonis wrote: >> >>>Hi Guys, >>> >>>time to go back to the original topic: >>> >>>here comes a 'disassembler_i486.cpp' that uses a vanilla >>>'libopcodes.so' how it comes with every binutils distribution. It can >>>be used as a simple replacement for the current >>>'disassembler_i486.cpp'. The only requirements during compile time is >>>'dis-asm.h' which is also provided by the binutils package. Usually >>>this should be availabel on Linux and should be no problem on Windows >>>as well if you use Cygwin anyway (I tried only on Linux). >>> >>>After compiling the HotSpot with the new version of >>>'disassembler_i486.cpp' you should now be able to use the various >>>print options like for example -XX:+PrintCompilation >>>-XX:+PrintAssembly, -XX:+PrintInterpreter and get a nice assembly >>>output of wht's going on under the hood. >>> >>>@chenjie: this should also work on MIPS as binutils support MIPS. >>>Could you check? Maybe it can be helpfull for your porting project. >>> >>>Implementation details >>>-------------------------- >>>I specially kept the diff to the original file small, so you can >>>easily see what the crucial changes are. If this should get into the >>>official release, we can of course get rid of a few things like for >>>example the class 'i486_env' and 'Disassembler::decode_instruction' >>>that arn't needed anymore. >>> >>>For other architectures, all that has to be done, is adapt the >>>following lines in 'init_disassemble_info()': >>> >>> // Platform dependent stuff (i486) >>> di.bytes_per_line = 0; >>> di.endian = (bfd_endian) 1; >>> di.mach = bfd_mach_i386_i8086; >>> di.disassembler_options = (char *) "i386,suffix"; >>> >>>and choose the right name for the disassembler function in >>>'Disassembler::load_library()': >>> >>>hpi::dll_lookup(_library, "print_insn_i386"); >>> >>>The specific names for other architectures can be found in 'dis-asm.h'. >>> >>>Pitfalls >>>-------- >>>On my Suse Linux 10 I had a broken 'libopcodes.so' ("nm >>>/usr/lib/libopcodes.so" returned no symbols. But building a new >>>version of binutils is quite tricky too, because you HAVE to give >>>./configure the "--enable-64-bit-bfd" option (even on 32bit Linux), >>>otherwise the resulting 'libopcodes.so' wont work! Heres my configure >>>line for building binutils 2.17: >>> >>>./configure --enable-shared --enable-64-bit-bfd >>> >>>Afterwards, just copy opcodes/.libs/libopcodes-2.17.so to /usr/lib and >>>let /usr/lib/libopcodes.so link to it. That's it. >>> >>>Regards, >>>Volker >>> >>>On 8/8/07, Peter B. Kessler wrote: >>> >>> >>>>Christian Thalinger wrote: >>>> >>>> >>>> >>>>>On Wed, 2007-08-08 at 12:45 -0700, Peter B. Kessler wrote: >>>>> >>>>>Hi Peter! >>>>> >>>>> >>>>> >>>>>>Could we move this thread from hotspot-compiler-dev at openjdk.dev.java.net >>>>>>to hotspot-compiler-dev at openjdk.java.net? The first list just forwards >>>>>>to the second list, but since you all are subscribed to the second list >>>>>>but not the first list, I have to approve all your postings to the first >>>>>>list. That means my lack of attention is just slowing you all down. >>>>>>I'm in the way to serve as a spam filter. (Part of garbage collection? :-) >>>>> >>>>>Hehe :-) >>>>> >>>>> >>>>> >>>>>>I assume most of you are just hitting "Reply-All" and so aren't even >>>>>>aware of the difference between openjdk.dev.java.net and openjdk.java.net. >>>>>>But you might also want to check your address books to see that new posts >>>>>>to hotspot-compiler-dev will go to openjdk.java.net. >>>>> >>>>>OK. This list? >>>>> >>>>>- twisti >>>> >>>> >>>>Yes. Thanks. Now, what was the original topic? :-) >>>> >>>> ... peter >>>> >>>> >>