From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S274825AbTGaRfN (ORCPT ); Thu, 31 Jul 2003 13:35:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S274822AbTGaRfN (ORCPT ); Thu, 31 Jul 2003 13:35:13 -0400 Received: from smtp6.Stanford.EDU ([171.67.16.33]:49066 "EHLO smtp6.Stanford.EDU") by vger.kernel.org with ESMTP id S274825AbTGaRfH (ORCPT ); Thu, 31 Jul 2003 13:35:07 -0400 To: linux-kernel@vger.kernel.org Subject: Re: Emulating i486 on i386 (was: TSCs are a no-no on i386) References: Reply-To: blp@cs.stanford.edu From: Ben Pfaff Date: 31 Jul 2003 10:35:00 -0700 In-Reply-To: Message-ID: <877k5y8urf.fsf@pfaff.Stanford.EDU> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jan-Benedict Glaw writes: > On Thu, 2003-07-31 16:12:26 +0100, Jamie Lokier > wrote in message <20030731151226.GG6410@mail.jlokier.co.uk>: > > Alan Cox wrote: > > > On Iau, 2003-07-31 at 12:38, Jan-Benedict Glaw wrote: > > > > See? It's loaded at the "ls" call, but it seems to be not loaded for > > > > apt-get. > > > > > > Remember you need to overload signal setting functions like sigaction. > > > My guess is apt decided to disable your signal and you didnt stop it > > > > An application might install its own SIGILL handler to emulate or trap > > _other_ instructions. To do it properly, you have to chain the handlers. > > > > Not sure how to do this, when you get to the stage of two LD_PRELOAD > > libraries each wanting to overload sigaction. > > That's not (yet) my problem and I think it's not impossible to hook > them. _But_ before, I need to get called at all _before_ libstdc++5's > _init(). For now, I haven't managed to do that... One way to get loaded before anything else is to do ELF binary loading by hand in userspace. The kernel exec loads your program, which sets up trap handlers etc., then loads the actual target binary by hand. I did this for an application sandbox. Writing the loader took less than half a day since I was able to use a lot of kernel code from binfmt_elf.c directly, just translating internal kernel calls into open, mmap, etc. system calls. -- "Note that nobody reads every post in linux-kernel. In fact, nobody who expects to have time left over to actually do any real kernel work will read even half. Except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea." --Linus