[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150525214512.GU17573@brightrain.aerifal.cx>
Date: Mon, 25 May 2015 17:45:12 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: ppc soft-float regression
On Mon, May 25, 2015 at 09:44:44AM +0200, Jens Gustedt wrote:
> > If we do want/need a fallback, it would need to be of the following
> > form:
> >
> > 1. Count addends that need to be saved.
> >
> > 2. If cnt<LIMIT (e.g. 16k), produce VLA of the right size; otherwise
> > produce VLA of size 1 and pass a null pointer instead of a pointer
> > to the VLA.
>
> Ok, so we have a simple sanity check, great.
>
> > 3. In stage 2, if the addend-buffer pointer is null, allocate storage
> > for it with __syscall(SYS_mmap, ...) (we can't call mmap yet).
> > Abort on failure.
> >
> > 4. In stage 3, if the addend-buffer was allocated donate it to malloc
> > after we're done using it.
> >
> > I would probably prefer just having it crash/abort in step 3,
>
> me too
>
> > since
> > this condition obviously indicates a broken build. It's better to
> > catch such an issue and fix it than to have a non-robust libc.so that
> > breaks fail-safety for no-third-party-libs binaries by depending on
> > allocation.
>
> Observe that I said "alternative strategy" not "fallback".
>
> "Crash early" to be that strategy sounds completely ok to me.
OK, sounds good. Here's the patch I'm testing now, which seems to work
fine. I'll probably commit it soon if there are no objections.
Rich
View attachment "save_and_reuse_addends_v1.diff" of type "text/plain" (5397 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
