Project

General

Profile

Bug #3205

ctfconvert does not handle zero-size structures

Added by Igor Kozhukhov over 8 years ago. Updated about 7 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2012-09-18
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

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

hvm.o (215 KB) hvm.o Igor Kozhukhov, 2012-09-18 11:02 PM
#1

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;
};
#2

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).

#3

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

Also available in: Atom PDF