From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8671 Path: news.gmane.org!not-for-mail From: Alex Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCHv3 1/3] fix matching errors for overwritten registers in x86 CFI generation script Date: Wed, 14 Oct 2015 21:44:50 +0200 Message-ID: References: <1444735732-12265-1-git-send-email-alexinbeijing@gmail.com> <20151013224204.GT8645@brightrain.aerifal.cx> <20151014191408.GU8645@brightrain.aerifal.cx> <20151014192736.GV8645@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1140f2eaaa71ba052215cb9c X-Trace: ger.gmane.org 1444851905 8755 80.91.229.3 (14 Oct 2015 19:45:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 19:45:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8683-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 14 21:45:04 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZmRyy-00082a-2l for gllmg-musl@m.gmane.org; Wed, 14 Oct 2015 21:45:04 +0200 Original-Received: (qmail 19977 invoked by uid 550); 14 Oct 2015 19:45:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 19951 invoked from network); 14 Oct 2015 19:45:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BhEhtiAvGmJYEor2eL+Kj6O95EzayNzmgrWmLtwI8nI=; b=BlzdQIysM7fb9Z6mfrEkGn0wriNus2OUQIGRtOvSxEkimvLFjZFE3+LghQg+uA45fO WOSjqddqTQadJ15UAuJ/CmKTUk4z00ICizaTh+hPK1BQmgUKXZjXS1u8UT4EM04rr24u A2HW7yQKG8ZUvvStkCmw5QnuOka2DAEHTCKz7fSwGqiwRW+Bo8k6MwF6weLrqyso+Wan MCVmlmZYFpPYmUw9JpZ11cnsjP9GlHR65SzWJf1nBfmbyCvKok5Ppm3hN9uezBtXcGs2 wnoA/jOhyO3O+xCUs6rFMpMuhkACnqpowJv6MRKV3ukIIWhD5tro+jpNBb989DqLzqir Wtqg== X-Received: by 10.107.151.195 with SMTP id z186mr5901506iod.89.1444851890153; Wed, 14 Oct 2015 12:44:50 -0700 (PDT) In-Reply-To: <20151014192736.GV8645@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8671 Archived-At: --001a1140f2eaaa71ba052215cb9c Content-Type: text/plain; charset=UTF-8 On Wed, Oct 14, 2015 at 9:27 PM, Rich Felker wrote: > On Wed, Oct 14, 2015 at 09:23:59PM +0200, Alex wrote: > > On Wed, Oct 14, 2015 at 9:14 PM, Rich Felker wrote: > > > > > On Wed, Oct 14, 2015 at 12:21:05PM +0200, Alex wrote: > > > > This has been an interesting exercise so far. Is there any other arch > > > which > > > > you think it would be worthwhile to develop a CFI generation script > for? > > > It > > > > should be something which has enough users to avoid problems with > bitrot. > > > > > > CFI is probably a lot less interesting on archs where you have a > > > plenty registers not to need to manipulate stack frames in asm > > > functions, since in that case the debugger mostly works fine without > > > CFI. I don't know right off which of the other archs have significant > > > amounts of asm that adjusts the stack pointer, but you could go > > > through and check them. Having ABI info for them all would be helpful; > > > I'm pasting my draft ABI reference (which might have errors) below. > > > > Fair enough. If it's not likely to help anyone, I'll leave the CFI > > generation here. > > > > Another idea: are you interested in an implementation of POSIX AIO which > > uses the native AIO syscalls? Bad idea? > > Those syscalls have nothing at all to do with POSIX AIO. They're > completely different. :( The interface presented by the raw syscalls is not the POSIX AIO interface, but I haven't seen any reason yet why io_setup, io_submit, io_getevents, etc. couldn't be used to implement the POSIX AIO interface. Is there such a reason? The payoff would be that you wouldn't have to spawn a thread for each AIO operation. Instead, you could potentially spawn just one extra thread, which would run in a loop, calling io_getevents() and doing some recordkeeping each time an AIO operation completed. AD --001a1140f2eaaa71ba052215cb9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 14, 2015 at 9:27 PM, Rich Felker <dalias@libc.org> wro= te:
On Wed, Oct 14, 2015= at 09:23:59PM +0200, Alex wrote:
> On Wed, Oct 14, 2015 at 9:14 PM, Rich Felker <dalias@libc.org> wrote:
>
> > On Wed, Oct 14, 2015 at 12:21:05PM +0200, Alex wrote:
> > > This has been an interesting exercise so far. Is there any o= ther arch
> > which
> > > you think it would be worthwhile to develop a CFI generation= script for?
> > It
> > > should be something which has enough users to avoid problems= with bitrot.
> >
> > CFI is probably a lot less interesting on archs where you have a<= br> > > plenty registers not to need to manipulate stack frames in asm > > functions, since in that case the debugger mostly works fine with= out
> > CFI. I don't know right off which of the other archs have sig= nificant
> > amounts of asm that adjusts the stack pointer, but you could go > > through and check them. Having ABI info for them all would be hel= pful;
> > I'm pasting my draft ABI reference (which might have errors) = below.
>
> Fair enough. If it's not likely to help anyone, I'll leave the= CFI
> generation here.
>
> Another idea: are you interested in an implementation of POSIX AIO whi= ch
> uses the native AIO syscalls? Bad idea?

Those syscalls have nothing at all to do with POSIX AIO. They're=
completely different. :(

The interface pres= ented by the raw syscalls is not the POSIX AIO interface, but I haven't= seen any reason yet why io_setup, io_submit, io_getevents, etc. couldn'= ;t be used to implement the POSIX AIO interface. Is there such a reason?

The payoff would be that you wouldn't have to sp= awn a thread for each AIO operation. Instead, you could potentially spawn j= ust one extra thread, which would run in a loop, calling io_getevents() and= doing some recordkeeping each time an AIO operation completed.
<= br>
AD
--001a1140f2eaaa71ba052215cb9c--