From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C5oQa-0006JN-Qg for qemu-devel@nongnu.org; Fri, 10 Sep 2004 12:39:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C5oQX-0006Hm-Sa for qemu-devel@nongnu.org; Fri, 10 Sep 2004 12:39:12 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C5oQX-0006Hc-Pl for qemu-devel@nongnu.org; Fri, 10 Sep 2004 12:39:09 -0400 Received: from [62.241.160.73] (helo=colossus.systems.pipex.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C5oKt-0002h1-6Q for qemu-devel@nongnu.org; Fri, 10 Sep 2004 12:33:19 -0400 From: Paul Brook Subject: Re: [Qemu-devel] IRIX host Date: Fri, 10 Sep 2004 17:33:15 +0100 References: <20040910122612.45544.qmail@web52503.mail.yahoo.com> <4141A950.2010100@bellard.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409101733.15506.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Friday 10 September 2004 17:15, Johannes Schindelin wrote: > Hi, > > I played around a little bit with dyngen in order to understand it. For my > own pleasure I tried to compile it on IRIX (HOST_MIPS). > > For your pleasure I write down what I learnt so far: > > I soon found out that gcc produces RELOCA objects, not RELOC: I added > HOST_MIPS specific code in the places where an "unsupported cpu" error > occurred - 3 places in total - , and inserted a printf to show which > relocations were found. With RELOC, there were none, with RELOCA, there > were some. I know I am lazy, probably I would have found out by RTFM. > > Also, it was quite easy to do the return finding stuff. I used "objdump > --disassemble-all i386-softmmu/op.o" to find out what the code looks like, > learning a little MIPS assembly on the way. Seems that "jr ra" is the > return statement, and "nop" are used to pad up to align to 8-byte > boundaries. IIRC MIPS has "branch delay slots", so these may not just be padding. > But now comes the biggest task: the relocations. In order to provide the > dynamically generated assembler code with the right parameters, C > functions for each assembler instruction are compiled into op.o, where a > placeholder is passed for each possible parameter. These parameters - > identified by their placeholders - will be filled in by the dynamic > compiler, dyngen_code(). This compiler is written by dyngen in the form of > a header file, op.h. > > Unfortunately this does not seem to work on IRIX as I expected it would: > If I understand correctly, and you want to reference a parameter (say > __op_param1), then the address of __op_param1 gets stored somewhere in a > global table, and the 16-bit offset in that table is actually stored in > the code. This sounds like you're generating PIC code. A few options spring to mind: - Generate non-pic code. I don't know if MIPS/IRIX has a non-pic option. - Change the definition of __op_param1 so it generates a more convenient relocation. - Do something clever with the GOT-indirect relocation. eg. turn it into a pc-relative reference to a constant pool. Paul