need help with UNIX/SPARC/ptrace() single stepping...

need help with UNIX/SPARC/ptrace() single stepping...

Post by Bradley Heath Powe » Fri, 29 Jan 1993 06:02:08



I am having GREAT difficulty finding information related to a academic project
that I am working on...can anyone help me???

THE SYSTEM:
   Sun SPARCstation 2
   SunOS 4.1.3  (very similar to UNIX)

THE PROJECT:
   I am writing a program that will record its child process' references to
memory addresses: i.e. every time the child process executes a load or store
machine instruction, the parent needs to write the address referenced and its
contents to a file.  Its purpose is to profile and evaluate the efficiency of
a process by examining its load and store instructions.

SOME QUESTIONS:
- How does one (or can one...) implement single step debugging in C with
  ptrace(), wait(), signal(), exec(), etc... under SunOS/UNIX?

- Where can I find information about the SPARC processor, particularly info.
  on encoding and decoding instructions? (yes, I've read the man pages and the
  answer book, and contacted Sun...but not enough info!)

- Where can I find a comprehensive tutorial on SPARC assembly language?

PLEASE HELP
   I would greatly appreciate any help that anyone can offer...please send
email to the address below.  I particularly need info. on where I can get
books and sample code.

Thanks-

Brad Powell

 
 
 

need help with UNIX/SPARC/ptrace() single stepping...

Post by Daniel Dign » Fri, 29 Jan 1993 09:39:03


I hacked up something that did something simlar to this once. It provided a way
of checking tah all writes and reads where to valid memory addresses. I took a
different approach.

Basically, you replace malloc with rou own written on top of memory mapping.
Then write protect the pages. Then every time a write is made you get an access
violation. Trap this, look at the data your given, the faulting address will be
one of these. Once you've logged the reference, return from you signal handler to
restart the faulting instruction.

This seemed to work fine, it was however very slow in our application, so as a
form of total paranoia it wasn't very useful. But it was an interesting hack.

You should be able to read protect pages as well, so this should cover all
references to allocated memory. It doesn't however cover references to stack,
or program data. Although the later could be done in a similar manner to
allocated memory.

--

Daniel Dignam  


    UUCP: {uunet,uupsi}!ug!daniel