Chuck.Rasbold at Sun.COM
Mon Aug 13 13:04:06 PDT 2007
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
-- 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
> hpi::dll_lookup(_library, "print_insn_i386");
> The specific names for other architectures can be found in 'dis-asm.h'.
> 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.
> 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:
>>>>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.
>>>OK. This list?
>>Yes. Thanks. Now, what was the original topic? :-)
>> ... peter
More information about the hotspot-compiler-dev