From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 09:22:50 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 49D23B78; Fri, 29 Mar 2013 09:22:50 +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 99031696; Fri, 29 Mar 2013 09:22:49 +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 r2T9MkOk077437; Fri, 29 Mar 2013 11:22:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2T9MkOk077437 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2T9MjhO077436; Fri, 29 Mar 2013 11:22:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Mar 2013 11:22:45 +0200 From: Konstantin Belousov To: Mikolaj Golub Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130329092245.GU3794@kib.kiev.ua> References: <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> <20130328105134.GO3794@kib.kiev.ua> <20130328211820.GA6657@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/27iTK9B7rPulYWO" Content-Disposition: inline In-Reply-To: <20130328211820.GA6657@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: Fri, 29 Mar 2013 09:22:50 -0000 --/27iTK9B7rPulYWO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 sections > > are specified to consists of entries, each of which is an array of 8-by= te > > 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 > 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 > 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 > BTW, looking at NetBSD code I see they set p_align in the note > segement to ELFROUNDSIZE: >=20 > /* Write out the PT_NOTE header. */ > ws.psections->p_type =3D PT_NOTE; > ws.psections->p_offset =3D notestart; > ws.psections->p_vaddr =3D 0; > ws.psections->p_paddr =3D 0; > ws.psections->p_filesz =3D notesize; > ws.psections->p_memsz =3D 0; > ws.psections->p_flags =3D PF_R; > ws.psections->p_align =3D ELFROUNDSIZE; >=20 > while we set to 0: >=20 > /* The note segement. */ > phdr->p_type =3D PT_NOTE; > phdr->p_offset =3D hdrsize; > phdr->p_vaddr =3D 0; > phdr->p_paddr =3D 0; > phdr->p_filesz =3D notesz; > phdr->p_memsz =3D 0; > phdr->p_flags =3D 0; > phdr->p_align =3D 0; You mean, for the core dumps ? >=20 > Shouldn't we set it to alignment size too? Note also, they set > "Segment is readable" flag. I think both changes are fine. I skimmed over the usermode parts of the patch. One thing I did not liked is the mis-handling of the read() return values. If there is short read, the errno value is meaningless, but warn() would still append it to the message. I suggest to explicitely distinguish -1 and >=3D 0 returns =66rom reads. --/27iTK9B7rPulYWO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRVV1lAAoJEJDCuSvBvK1BZGIQAJf+hjGDPWtSzNu9sKlfkux8 tPg8xPtVK+htzeZhHyugVqWDsw/rScuLJIvWrtTxgFCy9FMyLVtrDYpOU6OHxzd4 PvjQDLjX1Y/MmW/YC6nxe4apBg4MUzFEkCfrsovRR1IOFbCJOXI8+JYBfSte09Zn sKA5UfPjhoTuF+1GqL3i729zsOZCXbevIpdZ96DxJ0x3FLSQJfby4Jk/sG6CRZWQ R5HiErWfOGu79gA5gR3kHKtlpIQb4iY3TZAZn5L2Qklixjy46HTjlBMeYeRFZKGn 5+qRJAkgcuiXjMOlmXF96AIhzng0o0Ny2nKIW2UsjnTwYpLYGXJf5XSqPAWvnWTb dflSnmE0SGFIbY7rqyhH8xl41QJGvZk5trhxPZfM9qrxSot7r30ZF/aFmswMyh09 08Kp/DC5fP7OfOwnPDbfI4OFAzCDKRIvofTWFbntNb2BNM2eWSLZfm1zIQnpadhg XAGuUj6sbAuVYA75PCIFMW1wa4CTyLfcP82uiFzqOlnTVOHQwDOkQ4ZLGclFl7+S JteULxP+lQ60s1fDcoI9zQblNNqidnFp52WyCHgrOrSt73S4bm+ZImj61Ct98/hw NQKNzN6vrY1wH57CJmzGm38OQ+gbx9GPI2xC6IpvRMt4ay3yL19mFaFpmpZbVEfo WTP92/7u993K4AS7e+r/ =tmGP -----END PGP SIGNATURE----- --/27iTK9B7rPulYWO--