You are right, agent/make is historic make for engineers who only want
build SA alone. Certainly they can do this by
make -f sa.make from different platform locations. But that is only for
building sa-jdi.jar, for build libsaproc, they have to build after whole
hotspot built. In hotspot build the building order is sa-jdi.jar,
libjvm, libsaproc. I think to build libsaproc, we can do
make -f saproc.make
But I never try that.
Thanks
Yumin
On 2012/8/30 0:34, Staffan Larsen wrote:
My understanding is that the makefiles in the agent/make are not used
by normal build. Normal builds use make/<platform>/makefiles/sa.make.
It's unclear to me why the files under agent/make exist at all (except
for historical reasons).
/Staffan
On 29 aug 2012, at 19:22, Kelly O'Hair <kelly.oh...@oracle.com
<mailto:kelly.oh...@oracle.com>> wrote:
Makefiles buried in the src tree have a good chance of being
completely ignored by the new build-infra project.
We need some very solid control over all Makefiles used in the build
process.
The only exceptions have been test, sample, and demo makefiles, which
are not used in the jdk build process.
So if these Makefiles are used in the normal hotspot build process,
it would be much much better if they
were moved into the make directory with the rest of the makefiles.
-kto
On Aug 28, 2012, at 2:12 AM, Staffan Larsen wrote:
Thanks for picking up Tom's work and completing it. Anything that
removes 20k lines of code must be good :-)
Is there a way we can write a jtreg test for this? Either by
debugging a live JVM or a core file? Having a test would be very
helpful, although it may be impossible because of the requirement to
download and build binutils. Any other way we can add automatic
testing for this?
What platforms have you done manual testing on?
I noticed that the makefile changes are missing from the bsd makefiles.
Unrelated comment: we should remove the ia64 code from SA...
Thanks,
/Staffan
On 27 aug 2012, at 23:07, Yumin Qi <yumin...@oracle.com
<mailto:yumin...@oracle.com>> 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
