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.
pgpJEnpLmwEkV.pgp
Description: PGP signature
