libprocstat(3): retrieve process command line args and environment

[Konstantin Belousov]

On Sun, Mar 24, 2013 at 05:54:28PM +0200, Mikolaj Golub wrote:
> Here is an updated patch set, which I think includes all kib's
> suggestions. It also introduces procstat groups, umask, rlimit, and
> osrel notes.
> 
> http://people.freebsd.org/~trociny/procstat_core.3.patch
> 
> Sbuf section interface looks like below:
> 
> /* start a section */
> sbuf_start_section(sb, NULL);
> /* write something to sbuf */
> ...
> /* start a subsection (need to save the current section length) */
> sbuf_start_section(sb, &old_len);
> /* write something to sbuf */
> ...
> /* end a subsection padding to 4 bytes with '\0' bytes 
>   (need to provide the previously saved section length) */
> sbuf_end_section(sb, old_len, 4, 0);
> ...
>  /* aling the whole section to page size */
> sbuf_end_section(sb, -1, PAGE_SIZE, 0);
This looks fine.

> 
> Open issues/questions:
> 
> 1) I would also like to make libprocstat(3) extract environment, args,
> and auxv from the core. It looks like I don't need to store envv and
> argv in notes, as it is already present in the core. But I think I
> need to know psstrings to find them.
> 
> Would it be ok, if I add auxv and psstrings notes, and extract envv
> and agrv from a program section in the core?
Yes, I agree that not doing this in kernel at the time of the core
dump is preferred.

As usual, both args/env and aux vector could be overriden by the userspace,
so its reading is only best-efforts operation.

> 
> 2) I started NT_PROCSTAT constants from the first not used number in
> elf_common.h, i.e. 8. But in this case they conflict with those
> available on other systems:
> 
> contrib/binutils/include/elf/common.h:
> 
> #define NT_PSTATUS  10      /* Has a struct pstatus */
> #define NT_FPREGS   12      /* Has a struct fpregset */
> #define NT_PSINFO   13      /* Has a struct psinfo */
> #define NT_LWPSTATUS    16      /* Has a struct lwpstatus_t */
> #define NT_LWPSINFO 17      /* Has a struct lwpsinfo_t */
> #define NT_WIN32PSTATUS 18      /* Has a struct win32_pstatus */
> 
> Although note name = "FreeBSD" should have disambiguated this, readelf
> looks like ignores this and its output for my core on i386 looks
> confusing:
> 
>   Owner         Data size       Description
>   FreeBSD               0x0000006c      NT_PRPSINFO (prpsinfo structure)
>   FreeBSD               0x00000068      NT_PRSTATUS (prstatus structure)
>   FreeBSD               0x000000b0      NT_FPREGSET (floating point registers)
>   FreeBSD               0x00000018      NT_THRMISC (thrmisc structure)
>   FreeBSD               0x00000304      Unknown note type: (0x00000008)
>   FreeBSD               0x00000a6c      Unknown note type: (0x00000009)
>   FreeBSD               0x000008d4      NT_PSTATUS (pstatus structure)
>   FreeBSD               0x0000000c      Unknown note type: (0x0000000b)
>   FreeBSD               0x00000006      NT_FPREGS (floating point registers)
>   FreeBSD               0x000000d4      NT_PSINFO (psinfo structure)
>   FreeBSD               0x00000008      Unknown note type: (0x0000000e)
> 
> Should I use some other range for NT_PROCSTAT notes?
I think the only possible solution is to post on the binutils list
and fix the readelf ignore of the note vendor.

> 
> 3) Following our current code I align notes to sizeof(Elf_Size), which
> is 4 on i386 and 8 on amd64.
> 
> But I have an issue reading the notes by readelf on amd64, which alway
> uses 4 byte alignment:
> 
> contrib/binutils/binutils/readelf.c:
> 
>       next = (Elf_External_Note *)(inote.descdata + align_power (inote.descsz, 2));
> 
> where
> 
>   #define align_power(addr, align)    \
>   (((addr) + ((bfd_vma) 1 << (align)) - 1) & ((bfd_vma) -1 << (align)))
> 
> Should I change alignment to 4 bytes?
In the generic Elf 64bit draft specification I have, the notes sections
are specified to consists of entries, each of which is an array of 8-byte
words. I think we are right using the 8-byte alignment.

> 
> 4) In libprocstat I added new functions and placed them under already
> existent FBSD_1.3 version section in Symbol.map.
> 
> Shouldn't I bump the version? Won't I need any additional care if I
> want to MFC the code to stable/9 and may be 8?
Version of what ? MFC does not require any additional actions, FBSD_1.3
is the valid version namespace in 9 and 8.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130328/eeebfceb/attachment.sig>