From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: display word wrapping Date: 31 May 2004 09:34:34 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040530175117.C69B.LEKTU@mi.madritel.es> <9003-Sun30May2004202740+0300-eliz@gnu.org> <20040531013831.AA50.LEKTU@mi.madritel.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1085985188 10278 80.91.224.253 (31 May 2004 06:33:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 31 May 2004 06:33:08 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 31 08:33:02 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BUgM1-0003rC-00 for ; Mon, 31 May 2004 08:33:01 +0200 Original-Received: from lists.gnu.org ([199.232.76.165]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BUgM1-0007UO-00 for ; Mon, 31 May 2004 08:33:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BUgMC-0001fs-2m for emacs-devel@quimby.gnus.org; Mon, 31 May 2004 02:33:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BUgLu-0001fX-A8 for emacs-devel@gnu.org; Mon, 31 May 2004 02:32:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BUgLs-0001fD-FS for emacs-devel@gnu.org; Mon, 31 May 2004 02:32:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BUgLs-0001f9-91 for emacs-devel@gnu.org; Mon, 31 May 2004 02:32:52 -0400 Original-Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.34) id 1BUgLb-0000vN-EX; Mon, 31 May 2004 02:32:35 -0400 Original-To: Juanma Barranquero In-reply-to: <20040531013831.AA50.LEKTU@mi.madritel.es> (message from Juanma Barranquero on Mon, 31 May 2004 02:40:19 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:24268 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:24268 > Date: Mon, 31 May 2004 02:40:19 +0200 > From: Juanma Barranquero > > > How exactly is img->spec invalid? Can you post the details (xtype > > etc.)? > > Basically, img points to nowhere, so img->spec is some random value. Ah, yes, I forgot that Windows doesn't Page Fault on NULL pointer dereferences, but instead fetches some random garbage... > > If you change it to > > > > volatile struct image *img; > > > > does the problem go away as well? > > No. This probably means that the optimizer is not in itself the direct culprit here, as declaring img `volatile' should have prevented the compiler from keeping it in a register. However, this observation: > If I put > > __asm push img > img->load_failed_p = img->type->load (f, img) == 0; > __asm pop img > > (which forces a reload of the edi register from the stored value of img), > it works. seems to say that img is still in a register, even if declared `volatile'. Could you please look at the machine code near the invocation of "img->type->load (f, img)" and see whether `volatile' changes something there, and if so, what? Also, the above suggests that a work-around, if we don't find anything better, is to save img into a temporary variable before the call that clobbers it and restore it after that. But such a workaround needs to be more clever than the push/pop pair above, since it needs to update img->load_failed_p AFTER restoring img, not before it. > The register used to store img (edi, in my tests) is being modified by > this call: > > img->load_failed_p = img->type->load (f, img) == 0; IIUC, this boils down to calling gif_load (since the image file is GIF), right? If so, either the compiler didn't save and restore EDI around the call due to a bug in the compiler, or perhaps the compiler assumes something about the registers touched by gif_load or one of its subroutines (I suspect the DGif* functions from libungif), but those functions somehow violate that assumption. Does the code save and restore EDI around the call to img->type->load? If it did, perhaps the call to img->type->load clobbers the stack where EDI is saved. If EDI is not saved, could you trace where does EDI change inside gif_load? (FWIW, I think EDI should be saved here, as it is a register frequently used for keeping variables in optimized code.)