This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for i386 builds of glibc?
On Mon, Mar 04, 2013 at 07:20:35PM -0500, Carlos O'Donell wrote:
> On Mon, Mar 4, 2013 at 6:59 PM, Rich Felker <dalias@aerifal.cx> wrote:
> > Too bad. There's no requirement/guarantee that invoking undefined
> > behavior gives you SIGSEGV. In this case, SIGSEGV would be blocked at
> > the time of the fault, which, if I remember correctly, results in
> > either deadlock or process termination. Maybe not the ideal result
> > from a debugging standpoint, but a perfectly valid and conforming
> > implementation nonetheless.
>
> Yet there are some applications that expect to be able to rely on this
> to page things in/out. I know of interpreters that rely on SIGSEGV
> and the retry behaviour to bring in or interpret things lazily. This wouldn't
> work in this case?
As long as the function touched the memory first before doing
anything, it would cause it to be "paged in" if it wasn't already. If
the memory is subsequently "paged out" asynchronously, I think it's
unreasonable for an application to expect this not to break functions
which are part of libc that might be accessing the memory at the time
it's asynchronously unmapped out from under them.
> The signal handling solution introduces restrictions that didn't previously
> exist and would therefore likely to be unacceptable in the general case
> as opposed to a kernel solution.
I agree the kernel solution is much better and is the correct one if
anybody ever cared to support i386 again.
Rich