Bug 2458 - interface to obtain process|task ISA
Summary: interface to obtain process|task ISA
Status: NEW
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P3 normal
Target Milestone: ---
Assignee: Unassigned
Depends on:
Blocks: 1496
  Show dependency treegraph
Reported: 2006-03-14 14:25 UTC by Andrew Cagney
Modified: 2006-11-28 16:51 UTC (History)
1 user (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Cagney 2006-03-14 14:25:52 UTC

The kernel shall provide an interface, to directly, efficiently, robustly, and
statelessly (no attach) return a processes' ISA/ABI - instruction set
architecture / application binary interface.  Possible mechanims include:

ptrace (PT_ISA, ....)

Of course there are others.


- a system can support multiple ISAs: 32- vs 64-bit, ia64 vs ia32, ....  Frysk
needs to be able to correctly identify each.

- pulling information from memory or an executable is neither robust nor
efficient.  The information does not necessarially reflect the ISA/ABI of the
process; the relevant executables may not be available; the cost of the
operation, which includes doing an attach, is high.


The information, using heuristics to determine the byte-order and word-size, can
 be obtained from /proc/<pid>/auxv.
Comment 1 Wu Zhou 2006-03-15 14:12:59 UTC
Andrew, can you give a little more detail about the workaround?  How can we get
the ISA / ABI information from /proc/<pid>/auxv?

The auxv's definition is like this:

#define AT_NULL   0     /* end of vector */
#define AT_IGNORE 1     /* entry should be ignored */
#define AT_EXECFD 2     /* file descriptor of program */
#define AT_PHDR   3     /* program headers for program */
#define AT_PHENT  4     /* size of program header entry */
#define AT_PHNUM  5     /* number of program headers */
#define AT_PAGESZ 6     /* system page size */
#define AT_BASE   7     /* base address of interpreter */
#define AT_FLAGS  8     /* flags */
#define AT_ENTRY  9     /* entry point of program */
#define AT_NOTELF 10    /* program is not ELF */
#define AT_UID    11    /* real uid */
#define AT_EUID   12    /* effective uid */
#define AT_GID    13    /* real gid */
#define AT_EGID   14    /* effective gid */
#define AT_PLATFORM 15  /* string identifying CPU for optimizations */
#define AT_HWCAP  16    /* arch dependent hints at CPU capabilities */
#define AT_CLKTCK 17    /* frequency at which times() increments */

#define AT_SECURE 23   /* secure mode boolean */

There are OS / ABI information in program headers.  But /proc/<pid>/auxv can
only give us the offset of the program header.  We still need to read the target
program (in memory or hard-disk) to get the header?  Maybe I mis-understand
something.  Please point out.  Thanks.
Comment 2 Andrew Cagney 2006-05-05 18:15:31 UTC
The frysk.sys.proc.AuxvBuilder interface, through the buildDimensions() call
back, provides the byte order of the executable.  It figures it out through a
bit of reverse engineering - see frysk/sys/proc/cni/AuxvBuilder.cxx for details.
Comment 3 Wu Zhou 2006-05-25 05:53:30 UTC
Hi Andrew,

I am talking with Paul Mackerras about this.  He didn't see much need for kernel
to provide such an interface. His argument is like this:

how often are you going to want to ask what the ISA of a process is?
Only once per debugging session, surely, since the process can't change its
ISA.  So I don't see "that might mean to access the hard disk" as relevant.
In any case the ELF header is very likely to be in the page cache.  Your
other objection, that someone might have deleted the executable, isn't
valid, because you can still access /proc/<pid>/exe after the executable
has been deleted (I just tried it).

Unless you can show me a good reason why you need to query the ISA of large
numbers of processes many times per second, I think that looking at the
header of /proc/<pid>/exe is the best thing to do.  It is simple, fairly
cheap, well defined, and works on existing kernels.

Please note in above conversation with Paul, I provide a scanario that the user
delete the executable after running it as the example that the executable is not
available. It proved to be wrong. Can you please tell me any other examples for
this.  Maybe some kind of virus software who delete its trace in the file system
and /proc file system at the same time?