Question

[Chuck Rasbold]

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 <Chuck.Rasbold at sun.com> 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 <Peter.Kessler at sun.com> 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
>>>>
>>>>
>>