From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8673 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 22:27:17 +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> <20151014195141.GX8645@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1140f2ea86613f05221663ff X-Trace: ger.gmane.org 1444854463 19107 80.91.229.3 (14 Oct 2015 20:27:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 20:27:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8685-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 14 22:27:40 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 1ZmSe3-00088i-TM for gllmg-musl@m.gmane.org; Wed, 14 Oct 2015 22:27:32 +0200 Original-Received: (qmail 15546 invoked by uid 550); 14 Oct 2015 20:27:30 -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 15528 invoked from network); 14 Oct 2015 20:27:29 -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=0AhExtvZuCjKKNbd+kdg9NXTHq+E2DHrt2R2tExXFzM=; b=WL20S/S474N32+mubIwNo+8LnAvcafriZBZxpuz7wfGB3Rjyu314hDLXMJVl2FPOI9 CQlFTO4QtbEWE110nCAqo7vsMVAeDUI1uKM3JpVMpik3g5zxoKJal2MtBVym7SVDeIv5 x6RKBGhsjCCk89C8NfhgYjoftI0MlExy/LbjRCsLkaCJQZV359YK4InGSqUu8RenGnUA tAihsc5ioxsq6XuctZhzThqWcuh6jQ5KGW0sphcNIiO4fTIdEFpi6x945gLMZcF/5FVB KaTOPkmzNi/84vbVknqjjDFGNbb5E/IiVEvmF9tZ89oNPobt0kZbBzjoX/6I1pahqjbO x/ZQ== X-Received: by 10.107.151.195 with SMTP id z186mr6116576iod.89.1444854437915; Wed, 14 Oct 2015 13:27:17 -0700 (PDT) In-Reply-To: <20151014195141.GX8645@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8673 Archived-At: --001a1140f2ea86613f05221663ff Content-Type: text/plain; charset=UTF-8 On Wed, Oct 14, 2015 at 9:51 PM, Rich Felker wrote: > On Wed, Oct 14, 2015 at 09:44:50PM +0200, Alex wrote: > > 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? > > They only work on certain types of devices/files, and only when the > offset and memory source/dest meet some arbitrary alignment > requirements. And those are just the big problems. I don't see any > indication that they match the subtle behavior requirements for POSIX > AIO in any way. Gotcha, thanks. --001a1140f2ea86613f05221663ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 14, 2015 at 9:51 PM, Rich Felker <dalias@libc.org> wro= te:
On Wed, Oct 14, 2015 at 09:44:50PM +0200, Alex wrote:
> On Wed, Oct 14, 2015 at 9:27 PM, Rich Felker <dalias@libc.org> wrote:
>
> > 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 t= here 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 avoi= d problems with
> > bitrot.
> > > >
> > > > CFI is probably a lot less interesting on archs where y= ou 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 arch= s have significant
> > > > amounts of asm that adjusts the stack pointer, but you = could go
> > > > through and check them. Having ABI info for them all wo= uld be helpful;
> > > > I'm pasting my draft ABI reference (which might hav= e 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 POS= IX 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 inter= face,
> but I haven't seen any reason yet why io_setup, io_submit, io_gete= vents,
> etc. couldn't be used to implement the POSIX AIO interface. Is the= re such a
> reason?

They only work on certain types of devices/files, and only when= the
offset and memory source/dest meet some arbitrary alignment
requirements. And those are just the big problems. I don't see any
indication that they match the subtle behavior requirements for POSIX
AIO in any way.

Gotcha, thanks.=C2=A0
=
--001a1140f2ea86613f05221663ff--