From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 31 13:41:00 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 17EB11AF; Sun, 31 Mar 2013 13:41:00 +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 67DA7D87; Sun, 31 Mar 2013 13:40:59 +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 r2VDel2w065115; Sun, 31 Mar 2013 16:40:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r2VDel2w065115 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2VDelMq065114; Sun, 31 Mar 2013 16:40:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 31 Mar 2013 16:40:47 +0300 From: Konstantin Belousov To: Mikolaj Golub Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130331134047.GN3794@kib.kiev.ua> References: <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> <20130328105134.GO3794@kib.kiev.ua> <20130328211820.GA6657@gmail.com> <20130329092245.GU3794@kib.kiev.ua> <20130329123155.GA94024@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GclHhPKU8e6IjCj6" Content-Disposition: inline In-Reply-To: <20130329123155.GA94024@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 , freebsd-hackers@freebsd.org, Mikolaj Golub , "Robert N. M. Watson" 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: Sun, 31 Mar 2013 13:41:00 -0000 --GclHhPKU8e6IjCj6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 29, 2013 at 02:31:57PM +0200, Mikolaj Golub wrote: > On Fri, Mar 29, 2013 at 11:22:45AM +0200, Konstantin Belousov wrote: > > On Thu, Mar 28, 2013 at 11:18:21PM +0200, Mikolaj Golub wrote: > > > On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote: > > >=20 > > > > In the generic Elf 64bit draft specification I have, the notes sect= ions > > > > 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 > > > I have impression many implementations use 4-byte alignment. E.g. in > > > NetBSD: > > >=20 > > > sys/kern/core_elf32.c: > > >=20 > > > #define ELFROUNDSIZE 4 /* XXX Should it be sizeof(Elf_Word)?= */ > > > #define elfround(x) roundup((x), ELFROUNDSIZE) > > Note that this is core_elf32. I am concerned with the 64-bit cores. >=20 > core_elf64.c: >=20 > #define ELFSIZE 64 >=20 > #include "core_elf32.c" Also, the 4-bytes alignment is described in the comments in the glibc csu/abi-note.S. >=20 > > >=20 > > > Also, we have inconsistency with imgactl_elf.c/parse_notes(), which > > > uses 4-byte alignment: > > >=20 > > > note =3D (const Elf_Note *)((const char *)(note + 1) + > > > roundup2(note->n_namesz, sizeof(Elf32_Addr)) + > > > roundup2(note->n_descsz, sizeof(Elf32_Addr))); > > >=20 > > > I suppose there were no issues before, because accidentally the sizes > > > of all notes we had were 8 bytes aligned. > > Indeed, both ABI and NOINIT notes have size which is multiple of 8. > >=20 > > >=20 > > > Now, when I add new notes it will break things. I don't have strong > > > opinion, it will be ok for me to leave 8-byte alignment and fix > > > issues, just want to have strong support here :-) > > Well, while the issue is discussed and decided, you could just make > > your new notes size be multiple of 8 too. >=20 > I thought about this too. Then I need to be more caerful when > extracting stats from notes, because the length returned by > procstat_core_get() can be more than a real payload. >=20 > Ok, I will try this way. >=20 > I could add length to the note header, which is currently contains > only structsize, so it would became something like: >=20 > struct { > int structsize; > int lenght; > } >=20 > But not sure it is worth doing, especially if the forced 8-bit > alignment is a temporary mesure. No, it is definitely not worth it. I inspected imgact_elf.c:parse_note(), imgact_elf.c:putnote() and rtld.c:digest_notes(). Only putnote() uses 8-byte alignment. Every other OS and our !coredump code assumes 4-byte alignment. Does changing the putnote() to align on the 4-byte boundary cause real change in the core file notes layout ? --GclHhPKU8e6IjCj6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRWDzeAAoJEJDCuSvBvK1BSegQAIzbIjOxoFIJGt0T3+dT6hVf v00PMW3xK5S0Q/5oklc6AsanLIUjEe3p9L1LHpw6EG4d2tCiJ0eK6FyMyeo4tGib Vl6xRksd8dKDBgOEq0rqy6xfrx/JlwZHMft9AiYxS8vDsMiaP7zR7QcgHo/VW9PK MY8zYyaPLlYmTg65Qh80nDDmmW+Y/Z/kohfKQdXAEtbMvx2L8rIPJ0zcOj//spIJ Hoo3Ws0uDlTtkzvVeKcbja2dC/yhW6QtewvGJayrzN7GXijZYgdR92NTlrVhF8B+ ovnAdr7fX1bXzRCiazKdQsGpuw8CFqa2svE8fPCIIjnkrG8SuiWWwa7MZwYHHMAh XZW/txrojFD89DFSCIOC6wlf+/9OX1nKz7GotWzUvXHyofO6/TxrXi3+P+UKXvYd uV81WxgoKKWPICglU+JqUq2shbQuZccGemsgOgRLYJr7XE3gmats3/Y1eWv/wOhD omIBusMN9WirvWI+3F7/B+9MXiVi05rXHcSoAVsZIsBGoFnDV6d8hIn8fjQ9KHEy Sexr1kZIRkjgcQEX3j5RN5DRj3xP6l4O7V8mdt4jQNEq/sWZNrofFHBkBrveSlrH pP56saoa02KGRVZuSN2hrGrcaoPCtQmtm3h66OrfxqieEmny7QK6xnnKtvT/ZgYn RTFjxtx0SjKP3IV6RBSg =qwCX -----END PGP SIGNATURE----- --GclHhPKU8e6IjCj6--