From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33)
	id 1CfSj4-0000EQ-Aj
	for qemu-devel@nongnu.org; Fri, 17 Dec 2004 19:45:38 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33)
	id 1CfSj2-0000DR-9h
	for qemu-devel@nongnu.org; Fri, 17 Dec 2004 19:45:36 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.33) id 1CfSj2-0000DO-56
	for qemu-devel@nongnu.org; Fri, 17 Dec 2004 19:45:36 -0500
Received: from [132.187.3.35] (helo=wrzx35.rz.uni-wuerzburg.de)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1CfSA6-0004fT-0a
	for qemu-devel@nongnu.org; Fri, 17 Dec 2004 19:09:30 -0500
Date: Sat, 18 Dec 2004 01:09:26 +0100 (CET)
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [Qemu-devel] get_func() hangs with gcc 3.4.2 on MinGW and WinXP
	host
In-Reply-To: <20041217195627.A38776@saturn.kn-bremen.de>
Message-ID: <Pine.LNX.4.58.0412180107140.30351@wgmdd8.biozentrum.uni-wuerzburg.de>
References: <20041215134754.GA28410@100tka.net>
	<Pine.LNX.4.58.0412151515170.16529@wgmdd8.biozentrum.uni-wuerzburg.de>
	<20041215145903.GA29957@100tka.net>
	<20041215234503.GA12778@jbrown.mylinuxbox.org>
	<Pine.LNX.4.58.0412160049320.18774@wgmdd8.biozentrum.uni-wuerzburg.de>
	<20041217195627.A38776@saturn.kn-bremen.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Juergen Lock <qemu-l@jelal.kn-bremen.de>
Cc: qemu-devel@nongnu.org

Hi,

On Fri, 17 Dec 2004, Juergen Lock wrote:

> How about instead post-processing the .s, replacing the rets with jumps
> to the end of the function?  Of course this part would be architecture
> dependant (different assembler syntax), but other parts of qemu
> are that as well, right?

It would be architecture dependant, right. But it would be better to fix
the compilation of op.c, so that you really can chain the op_* functions.
What I mean: if you work on it, you could as well do it such that you gain
the most (performance) of it.

Ciao,
Dscho