0

The Wikipedia article on ptrace says:

Communications between the controller and target take place using repeated calls of ptrace, passing a small fixed-size block of memory between the two (necessitating two context switches per call); this is acutely inefficient when accessing large amounts of the target's memory, as this can only be done in word sized blocks (with a ptrace call for each word).[7] For this reason the 8th edition of Unix introduced procfs, which allows permitted processes direct access to the memory of another process - 4.4BSD followed, and the use of /proc for debugger support was inherited by Solaris, BSD, and AIX, and mostly copied by Linux

Is faster memory access the only thing that a debugger would care about that /proc allows but which is not possible with ptrace? For example, is there more debugger-relevant information about the running program available through /proc? What about additional debugger-relevant ways to manipulate programs? Would /proc be generally more efficient than ptrace, or is reading large blocks of memory the only noticeably less performant case?

ctrl-alt-delor
  • 27,473
  • 9
  • 58
  • 102
Ryan1729
  • 591
  • 1
  • 4
  • 7

1 Answers1

2

If the debugger likes to access the other process via ptrace(), it can only access a machine word at a time using an expensive system call per word.

Procfs on the other side provides /proc/<pid>/as which is the whole address space of the process seen in a file. On that file, read(), write() and lseek() work and this makes access to the other process faster.

But procfs also gives more information about the process than ptrace() that only delivers registers and address space access, as well as features like singlestep and similar.

The truss(1) utility was written by Roger Faulkner as part of the procfs. This is based on another interface that has been unique to procfs in 1986, but SunOS did enhance the ptrace() system call in 1988 to offer the the same functionality without a need to have procfs. SunOS did call the related program trace(1).

Procfs also offers /proc/<pid>/psinfo for the ps command. Beforeprocfs was available, ps did read /dev/kmem to print information about the process and the way such information is retrieved makes it unreliable.

BTW: if you like to single step another process via procfs, this is done via an ioctl() ona file from procfs, while ptrace() offers a subcommand as a system call to do the same. Today ptrace() is implemented as a libc wrapper around procfs features.

Also note that Solaris not only offers the procfs, but Sun Microsystems did also hire Roger Faulkner the inventor of procfs. This is where he developed amongst others procfs2.

What Linux offers as procfs is neither compatible to procfs1 nor to procfs2.

To check that Solaris implements ptrace via procfs,see: https://sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/src/lib/libc/i386/sys/ptrace.c

schily
  • 18,806
  • 5
  • 38
  • 60
  • The wikipedia article I liked goes on to say that Solaris implements `ptrace` with `/proc`, but you're saying that this is broadly true of other Unix-likes as well? Interesting. Just to make sure I understand, would a fair summry be that `/proc` allows doing everything `ptrace` can do, plus some other things like information for the `ps` command, and possibly other features, but it will depend on the particular OS we're talking about? – Ryan1729 Jul 04 '20 at 13:58
  • Solaris does, see the pointer the source. Whether other OS do the same depends on whether they are based on SVr4 or not. – schily Jul 04 '20 at 15:00