[MC assembler] default suffix of fld mnemonic?

[DimitryAndric]

Bugzilla Link	8687
Resolution	DUPLICATE
Resolved on	Nov 25, 2010 08:16
Version	trunk
OS	FreeBSD
CC	@asl

Extended Description

In the FreeBSD tree, there exists this fragment of inline assembly in a
.c file:

    float x;
...
    __asm __volatile("ffree %%st(7); fld %0" : : "m" (x));

This gets compiled to the following preprocessed assembly:

ffree	%st(7)
fld	-4(%ebp)

Though the fld mnemonic misses a size suffix such as 's', gas assembles
it anyway, and apparently interprets it as a float operation:

6: dd c7 ffree %st(7)
8: d9 45 fc flds 0xfffffffc(%ebp)

I'm not sure what the right approach is here; it seems rather arbitrary
to use flds by default, but apparently that's what gas does.

[asl]

The best thing will be just to reject such bogus assembler, not to interpret it randomly. I though such a change recently was added, what is the problem you're seeing?

[DimitryAndric]

Ah sorry, I did not explain properly what the actual problem was. :)

The code above gives the following error with clang trunk r119964:

npx.c:941:19: error: ambiguous instructions require an explicit suffix (could be 'flds', 'fldl', or 'fldt')
__asm __volatile("ffree %%st(7); fld %0" : : "m" (dummy_variable));
^
:1:16: note: instantiated into assembly here
ffree %st(7); fld fpu_clean_state.dummy_variable
^

Apparently, gas changes plain 'fld' to 'flds' automatically, because
even if I replace the 'float' with 'double', the resulting object file
still uses 'flds':

b6e: dd c7 ffree %st(7)
b70: d9 05 00 00 00 00 flds 0x0

[asl]

Ok, this is expected behavior. Please fix the bogus sources.

*** This bug has been marked as a duplicate of bug #8900 ***

[DimitryAndric]

Just as a closing note, the ambiguous code in question was introduced as
a fix for the following security advisory from 2006:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1056

So you can expect this code to pop up in a lot of places... :)

[asl]

Just as a closing note, the ambiguous code in question was introduced as
a fix for the following security advisory from 2006:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1056

So you can expect this code to pop up in a lot of places... :)
I don't think so. This issue seems to be a problem of a particular implementation only. See, e.g. http://security.freebsd.org/advisories/FreeBSD-SA-06:14-amd.txt where proper instruction suffixes are used.

[DimitryAndric]

Unfortunately, everybody seems to have copied the bad example from
FreeBSD. :)

See for example OpenBSD's change:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/isa/npx.c.diff?r1=1.38;r2=1.39

NetBSD did the same:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/isa/npx.c.diff?r1=1.111&r2=1.112&only_with_tag=MAIN

Later they moved the code in question to a separate 'fldummy' function,
but still with the "naked" fld instruction:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/i386/cpufunc.S?only_with_tag=MAIN

Luckily, Linux used 'fildl', as in the original AMD advisory...:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=18bd057b1408cd110ed23281533430cfc2d52091

In any case, it is better to fix the ambiguities.