From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 10:51:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 814D5B14; Thu, 28 Mar 2013 10:51:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CEAC2D6D; Thu, 28 Mar 2013 10:51:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2SApY8J036055; Thu, 28 Mar 2013 12:51:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2SApY8J036055 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2SApYob036054; Thu, 28 Mar 2013 12:51:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Mar 2013 12:51:34 +0200 From: Konstantin Belousov To: Mikolaj Golub Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130328105134.GO3794@kib.kiev.ua> References: <201301251531.43540.jhb@freebsd.org> <20130212215054.GA9839@gmail.com> <201302200904.15324.jhb@freebsd.org> <20130220195801.GA8679@gmail.com> <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> <20130317063033.GL3794@kib.kiev.ua> <20130317091930.GA2833@gmail.com> <20130324155426.GA87022@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kDCrHF7AtgO4AaDI" Content-Disposition: inline In-Reply-To: <20130324155426.GA87022@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Stanislav Sedov , Attilio Rao , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 10:51:39 -0000 --kDCrHF7AtgO4AaDI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > http://people.freebsd.org/~trociny/procstat_core.3.patch >=20 > Sbuf section interface looks like below: >=20 > /* 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=20 > (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. >=20 > Open issues/questions: >=20 > 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. >=20 > 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. >=20 > 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: >=20 > contrib/binutils/include/elf/common.h: >=20 > #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 */ >=20 > Although note name =3D "FreeBSD" should have disambiguated this, readelf > looks like ignores this and its output for my core on i386 looks > confusing: >=20 > Owner Data size Description > FreeBSD 0x0000006c NT_PRPSINFO (prpsinfo structure) > FreeBSD 0x00000068 NT_PRSTATUS (prstatus structure) > FreeBSD 0x000000b0 NT_FPREGSET (floating point regis= ters) > 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 registe= rs) > FreeBSD 0x000000d4 NT_PSINFO (psinfo structure) > FreeBSD 0x00000008 Unknown note type: (0x0000000e) >=20 > 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. >=20 > 3) Following our current code I align notes to sizeof(Elf_Size), which > is 4 on i386 and 8 on amd64. >=20 > But I have an issue reading the notes by readelf on amd64, which alway > uses 4 byte alignment: >=20 > contrib/binutils/binutils/readelf.c: >=20 > next =3D (Elf_External_Note *)(inote.descdata + align_power (inote.= descsz, 2)); >=20 > where >=20 > #define align_power(addr, align) \ > (((addr) + ((bfd_vma) 1 << (align)) - 1) & ((bfd_vma) -1 << (align))) >=20 > 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. >=20 > 4) In libprocstat I added new functions and placed them under already > existent FBSD_1.3 version section in Symbol.map. >=20 > 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. --kDCrHF7AtgO4AaDI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRVCC1AAoJEJDCuSvBvK1BRTEP/2xe3QXaEVtZnhl1ONnfZSzU DZomEhZkMHxR+BIMQ+jCchCXFl8bbzXDcYPv6qOu/zoy17iiqHu231PB9dmqBUgG V4vcHPXh2VN6k7AWff5JT8pGUiXrIPB905gzetjk+vXt+1hJ5zY8M0c6TxcnEaOG XXCMp88F1+yrXRZ50GjyMUSmqZLDAlUduuk6EAEEam1mLqegKsKVqAXY1IvepG5e 42/9eJ1x2Om1dzNfSOA4dwjpNcqeFsYrQZ6rwCZUlvXSyCZTf8XTSc+5jY8AX/vW rTqI9/ydoEfU2NIsp/LmN/tEC16mbLUUSfXQUuei8IkUbdiydXN2qQ0PptccKC58 xX1JlREyHTfQ1knXbpxHqI20HCKYo6jzlsxe76+E7e4Ch6Y8Cwaj3p/VfsE09Ils ECO2JrpUhovM9U1R+CUakNS7A8VUyXLBR5QQBZQrwaEnQkXI/gg8CXWvcQX2Bhx0 MkkzTRxGg382FUtESbqCYY9HLfyBQpWfhhGCQQAz1ahJIM1llsSMhLBcYcvgZ7IG ey3at9xtW4tafA659jDWSdxkOP4jmKEQdcy1/tV1m1DeiSBNEv/KRug9k6kmDpMx kJIwnOlqvzeAvF6bYZ7SmC/mPnr42YDSQf5EPgRz90IF6sArSRghujJpDH5rSaVW QZA518XsK2A0pRlpLJCS =29ax -----END PGP SIGNATURE----- --kDCrHF7AtgO4AaDI--