[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: display word wrapping
From: |
Eli Zaretskii |
Subject: |
Re: display word wrapping |
Date: |
31 May 2004 09:34:34 +0200 |
> 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.)
- Re: display word wrapping, (continued)
- Re: display word wrapping, David Kastrup, 2004/05/31
- Re: display word wrapping, Jason Rumney, 2004/05/28
- Re: display word wrapping, Kim F. Storm, 2004/05/28
- Re: display word wrapping, Juanma Barranquero, 2004/05/28
- Re: display word wrapping, Juanma Barranquero, 2004/05/29
- Re: display word wrapping, Juanma Barranquero, 2004/05/29
- Re: display word wrapping, Eli Zaretskii, 2004/05/30
- Re: display word wrapping, Juanma Barranquero, 2004/05/30
- Re: display word wrapping, Eli Zaretskii, 2004/05/30
- Re: display word wrapping, Juanma Barranquero, 2004/05/30
- Re: display word wrapping,
Eli Zaretskii <=
- Re: display word wrapping, Juanma Barranquero, 2004/05/31
- Re: display word wrapping, Andreas Schwab, 2004/05/31
- Re: display word wrapping, Eli Zaretskii, 2004/05/31
- Re: display word wrapping, Eli Zaretskii, 2004/05/31
- Re: display word wrapping, Juanma Barranquero, 2004/05/31
- Re: display word wrapping, Juanma Barranquero, 2004/05/31
- Re: display word wrapping, Andreas Schwab, 2004/05/31
- Re: display word wrapping, Juanma Barranquero, 2004/05/31
- Re: display word wrapping, Miles Bader, 2004/05/31
- Re: display word wrapping, Juanma Barranquero, 2004/05/31