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. > > Ok. > > > >> 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 <[EMAIL PROTECTED]> r870 with some minor whitespace cleanups. From this point on, please flame me about this rather then Robert. Thank you. Jordan -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
