Bug #3205
ctfconvert does not handle zero-size structures
0%
Description
/opt/onbld/bin/i386/ctfconvert -i -L XEN_FULLVERSION hvm.o
ctfconvert: failed to resolve the following types:
struct 10996: failed to size member "ymm" of type (anon) (10958)
ERROR: ctfconvert: failed to resolve types
object file attached
Files
Updated by Robert Mustacchi over 8 years ago
- Subject changed from ctfconvert: failed to resolve the following types to ctfconvert does not handle zero-length arrays
- Tags deleted (
needs-triage)
ctfconvert is encountering a structure that has a zero length array at the end of it and is complaining. The following structure is what it complains on:
struct hvm_hw_cpu_xsave { uint64_t xfeature_mask; uint64_t xcr0; /* Updated by XSETBV */ uint64_t xcr0_accum; /* Updated by XSETBV */ struct { struct { char x[512]; } fpu_sse; struct { uint64_t xstate_bv; /* Updated by XRSTOR */ uint64_t reserved[7]; } xsave_hdr; /* The 64-byte header */ struct { char x[0]; } ymm; /* YMM */ } save_area; };
Updated by Rich Lowe over 8 years ago
- Subject changed from ctfconvert does not handle zero-length arrays to ctfconvert does not handle zero-size structures
It's not failing because of the 0-length flexible-array analogue (a GNU extension), but because it causes us to have a 0-length structure.
It appears (based on info from Robert) that GCC is willing to accept a 0-size structure in this case, despite the fact that the true C99 flexible member is forbidden in this case (and probably for this reason).
Updated by Igor Kozhukhov about 7 years ago
Rich Lowe wrote:
It's not failing because of the 0-length flexible-array analogue (a GNU extension), but because it causes us to have a 0-length structure.
It appears (based on info from Robert) that GCC is willing to accept a 0-size structure in this case, despite the fact that the true C99 flexible member is forbidden in this case (and probably for this reason).
comments from Xen community:
The structure is variable length depending on whether the VM has enabled AVX support.
It is rather unfortunate that we have non-complient C used to specify the ABI.
can we use here ?
struct { char x1; } ymm;
No, it wont.
The 'ymm' is either not present and has a size of 0 as far as save_area is concerned, or is present, and has a size of 16 * 256bit registers.
The content of this structure is only relevant as far as hvm_{save,load}_cpu_xsave_states() goes, which resorts to some pointer-trickary to move the data. Changing that char x0 to char x1 will break the pointer trickary, and migration will suffer an ABI breakage.
-Andrew