Bug 2458

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.

Whu,
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.
Andrew

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?

Thanks.