From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Problem with library images on Windows (again) Date: Thu, 19 May 2005 00:44:46 +0200 Message-ID: References: Reply-To: Juanma Barranquero NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1116457021 25986 80.91.229.2 (18 May 2005 22:57:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 18 May 2005 22:57:01 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 19 00:56:58 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DYXS2-0004Wu-Fl for ged-emacs-devel@m.gmane.org; Thu, 19 May 2005 00:55:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DYXUY-0007Yg-Rp for ged-emacs-devel@m.gmane.org; Wed, 18 May 2005 18:58:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DYXLU-0001al-Ca for emacs-devel@gnu.org; Wed, 18 May 2005 18:48:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DYXLS-0001Zl-95 for emacs-devel@gnu.org; Wed, 18 May 2005 18:48:54 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DYXLR-0001Qx-HN for emacs-devel@gnu.org; Wed, 18 May 2005 18:48:53 -0400 Original-Received: from [64.233.184.203] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DYXPY-0003Vk-Bt for emacs-devel@gnu.org; Wed, 18 May 2005 18:53:09 -0400 Original-Received: by wproxy.gmail.com with SMTP id 50so433574wri for ; Wed, 18 May 2005 15:44:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EUFiL+vw/MS9tRAQZ7QK246ecin1KYELuaQlkerDnafcC65X3P0N4FV7A3lsv93JP7J65cDwTVGLC1Iku2vC3h6syfsoNrRV4Ci1m7IXtt28uOuayOwbQVtG13MfA85S+qdAfdJkzxunWoFUH5/JGpTwNNojM9HhKsVimInAumM= Original-Received: by 10.54.40.38 with SMTP id n38mr581657wrn; Wed, 18 May 2005 15:44:46 -0700 (PDT) Original-Received: by 10.54.82.6 with HTTP; Wed, 18 May 2005 15:44:46 -0700 (PDT) Original-To: emacs-devel@gnu.org In-Reply-To: Content-Disposition: inline X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:37311 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:37311 > That's quite different from the Unix calling conventions on i386, where > only EAX, ECX and EDX are call-clobbered. I was wrong wrt the MSVC calling conventions. MSDN docs say: All arguments are widened to 32 bits when they are passed. Return values are also widened to 32 bits and returned in the EAX register, except for 8-byte structures, which are returned in the EDX:EAX register pair. Larger structures are returned in the EAX register as pointers to hidden return structures. Parameters are pushed onto the stack from right to left. The compiler generates prolog and epilog code to save and restore the ESI, EDI, EBX, and EBP registers, if they are used in the function. so it seems it's the same calling convention than on i386 Unixes: EAX and EDX can be clobbered to return the function's result, and ECX because it is not saved. > That appears like a blatant bug in the compiler if it cannot properly > track call-clobbered registers. There's a bug somewhere, that's pretty clear. Whether that's an error of the MSVC compiler or the MinGW libraries, I'm not sure yet. I've been tracing lookup_image, and the fact is, the lookup_image code is using EBX to cache "spec", and rightly so. But the call to tiff_load (via img->type->load()) clobbers EBX! --=20 /L/e/k/t/u