Question

[Volker Simonis]

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
> >>
> >>
>