Re: display word wrapping

[Eli Zaretskii]

> Date: Mon, 31 May 2004 02:40:19 +0200
> From: Juanma Barranquero <address@hidden>
> 
> > 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.)