jordan.crouse at amd.com
Wed Sep 24 16:57:30 CEST 2008
On 23/09/08 20:01 +0200, Robert Millan wrote:
> On Tue, Sep 23, 2008 at 04:11:34PM +0200, Mathias Krause wrote:
> > > I see. But why not just add "ecx" to clobber list instead? Then a dummy
> > > variable isn't needed.
> > When doing so the compiler is unable to find another register called
> > %ecx to assign the value of f as input value. He cannot use %ecx because
> > by mentioning it in the clobber list you already told him that register
> > may change it's value at any time within the asm statement. That for the
> > "kudge" with the dummy output variable is needed but it should get
> > optimized away since it's value is never used. It's only usage is to
> > tell the compiler that the value of %ecx has changed.
> > >> The memory clobber is needed since you cannot know what the called
> > >> function will actually do with the memory and to ensure all cached
> > >> values are actually written back to memory before calling f().
> > >
> > > Is this really a problem? If the payload expects to return, it isn't
> > > supposed to modify coreboot's memory at all. If it does, I'd say it's
> > > normal that things break.
> > Not the return of f() is the problem but missing memory writes _before_
> > calling it. If coreboot does some memory modifications that are relevant
> > for f() they should be taken out of registers and written back to memory
> > before calling f(). Otherwise f() may break.
> Makes sense. Thanks for the explanation.
> Here's a new patch incorporating your suggestions.
> Robert Millan
> The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
> how) you may access your data; but nobody's threatening your freedom: we
> still allow you to remove your data and not access it at all."
> Signed-off-by: Robert Millan <rmh at aybabtu.com>
r870 with some minor whitespace cleanups. From this point on, please
flame me about this rather then Robert. Thank you.
More information about the coreboot