Hi Phil,
Thank you for your quick response. I actually am aware of the strace utility (that is what I used to verify that the trap instruction 16 was occuring too frequently). Unfortunately, simply aquiring a trace of the system calls isn't my end goal, rather it is just the first step, and really I am using it as a way to teach myself the in's and out's of Simics/Gems.
I did also post my message on the Simics.net forum, but I have always been impressed with the replies topics receive on this list. Also, I thought that in particular this list might have many experts at using Simics, and in many cases, with SPARC. My goal is to be able to complete as much within Simics (using Python scripts) as possible for functional testing/profiling, and then use Opal modifications for timing results.
By the way, your suggestion to use magic break points proved very valuable. I programmed a small C program that opened a file using the Open system call and put magic break points around that and was able to take the instruction trace and narrow down the occurance of the system call (it seems that unfortunately trap 16 is used for system calls as well as other forms of traps).
Thanks again for your reply and suggestions,
James
On 11/8/06, Philip Garcia <pcgarcia@xxxxxxxx
> wrote:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The easiest way to determine what system calls are being used would
be to run something like strace on the running software (within the
simulator) on the code your running. This is a standard linux
command that outputs the system calls being made. This would be most
useful when running on simics without gems (as the timing accuracy
when using strace is lost already). What you might also want to look
into doing is modifying the linux kernel to call the magic
instruction every time a system call is made (I'm not 100% sure how
the handler is done for this), then use simics methods to view the
instruction stream prior to this. However all of this work would
work best in using just simics to handle it. Even a method as simple
as adding a magic instruction in a single system call and writing a
test program that calls that system call should work for that
process. Then you can figure out from the instruction trace which
instruction caused the trap, and how they work. I am not as familiar
with how to do a lot of this in simics, but I would recommend using
the
simics.net forum for more questions related to strictly simics
related questions. Their are many experts on that forum (including
simics employees) who are quite good about answering questions you
may have. For more information on modifying the Linux kernel, I'd
recommend the o'reilly device drivers programming book, the
understanding the linux kernel book is also useful, but tends to be
more x86-specific than the device drivers book.
Phil
On Nov 8, 2006, at 1:15 PM, James Poe wrote:
> I apologize in advance as the bulk of these two questions relate to
> Simics as opposed to Gems directly, but I would really appreciate
> it if some of the experts that have been using both on this list
> could point me in the right direction.
>
> I was wondering if anyone has had any experience with system calls
> on the Simics/Linux/Sunfire dumps. I am very new to both Simics
> and Sparc ISA. From the architectural manuals, it seems that
> system calls are invoked using the ta (trap all) instruction.
> However, after printing out a trace of the instructions, it appears
> that the ta instruction only appears in two forms (as a
> Trap_Instruction_3 and a Trap_Instruction_16). Unfortunately it
> seems as though 3 occurs far too infrequently, and 16 too
> frequently (for instance even when the terminal is idle) to be
> system calls. Does anyone know what I might be overlooking, or how
> to detect system calls using the base Simics framework running the
> Linux/Sparc ISA? Also, does Gems have any knowledge of System Calls?
>
> Also, as I am very new to Simics, I was wondering if anyone knew of
> a source of example scripts that I could use to teach myself from.
> I've looked through most of the documentation manuals that come
> with the academic version of Simics but I'm still a bit lost.
> Examples of the types of things I would like to be able to do in
> the future would be to record specific register values on every
> system call, access stack pointers at certain times, etc.
>
> Thanks in advance for any direction you can provide,
>
> James
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
>
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding
> "site:https://lists.cs.wisc.edu/archive/gems-users/
" to your search.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFFUkT6kSK2LwjyZ3wRAqAlAJ9g+4Tb079SVpTJJ5mlGlx09lBRpwCfR2Dw
z+t5wNS8OfMY1vhMcWpUgH0=
=azNy
-----END PGP SIGNATURE-----
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}