RFR: 6879063: SA should use hsdis for disassembly

yumin.qi at oracle.com yumin.qi at oracle.com
Tue Aug 28 08:47:57 PDT 2012


  Thanks. Will do.

Yumin

On 8/28/2012 3:19 AM, Vladimir Ivanov wrote:
> Yumin,
>
> Nice work!
>
> Since you touch src/share/tools/hsdis/Makefile, can you fix the
> following typo as well?
>
> --- a/src/share/tools/hsdis/Makefile    Fri Aug 24 16:23:59 2012 -0700
> +++ b/src/share/tools/hsdis/Makefile    Tue Aug 28 14:16:07 2012 +0400
> @@ -118,7 +118,7 @@
>   BINUTILSDIR    = $(shell cd $(BINUTILS);pwd)
>   endif
>
> -CPPFLAGS       += -I$(BINUTILSDIR)/include -I$(BINUTILS)/bfd
> -I$(TARGET_DIR)/bfd
> +CPPFLAGS       += -I$(BINUTILSDIR)/include -I$(BINUTILSDIR)/bfd
> -I$(TARGET_DIR)/bfd
>   CPPFLAGS       += -DLIBARCH_$(LIBARCH) -DLIBARCH=\"$(LIBARCH)\"
> -DLIB_EXT=\"$(LIB_EXT)\"
>
>   TARGET_DIR     = build/$(OS)-$(JDKARCH)
>
> Best regards,
> Vladimir Ivanov
>
> On 08/28/12 01:07, Yumin Qi wrote:
>>   Hi, all
>>
>>    Can I have you code review of
>>    6879063: SA should use hsdis for disassembly
>>
>>    http://cr.openjdk.java.net/~minqi/6879063
>> <http://cr.openjdk.java.net/%7Eminqi/6879063/>
>>
>>    The SA has Java based disassemblers for x86 and sparc but amd64.
>> Instead of porting to amd64 we should switch over to using hsdis for it
>> like the JVM does.  This requires a new entry point into hsdis,
>> decode_instructions_virtual, which separates the address of the code
>> being disassembled from the buffer containing the code.  The existing
>> uses of decode_instructions have been updated to use the new interface
>> and SA Disassembler has Java native methods that call into hsdis and
>> call back up to Java to perform the disassembly. Also changed makefile
>> for hsdis build for both(i386/amd64).
>>
>>    All the old disassembler logic was deleted since it's incompatible
>> with the new disassembly interface. Also deleted are dbx based SA
>> interface and few other dead files.
>>
>>    Tested by dumping full assembly from core files.
>>
>>    Reviewed-by:
>>    Contributed-by: Tom R (never)
>>
>>    Thanks
>>    Yumin Qi
>>


More information about the serviceability-dev mailing list