为什么LLVM IR结构中的函数指针字段被{} *替换？

Question

I compiled the MUSL C library using Clang 3.3, and dumped the generated LLVM IR files. I found that the FILE struct

struct __FILE_s {
    unsigned flags;
    unsigned char *rpos, *rend;
    int (*close)(FILE *);
    unsigned char *wend, *wpos;
    unsigned char *mustbezero_1;
    unsigned char *wbase;
    size_t (*read)(FILE *, unsigned char *, size_t);
    size_t (*write)(FILE *, const unsigned char *, size_t);
    off_t (*seek)(FILE *, off_t, int);
    unsigned char *buf;
    size_t buf_size;
    FILE *prev, *next;
    int fd;
    int pipe_pid;
    long lockcount;
    short dummy3;
    signed char mode;
    signed char lbf;
    int lock;
    int waiters;
    void *cookie;
    off_t off;
    char *getln_buf;
    void *mustbezero_2;
    unsigned char *shend;
    off_t shlim, shcnt;
};

was compiled as

%struct.__FILE_s = type { i32, i8*, i8*, 
i32 (%struct.__FILE_s*)*, i8*, i8*, i8*, i8*, 
i64 (%struct.__FILE_s*, i8*, i64)*, 
i64 (%struct.__FILE_s*, i8*, i64)*, 
i64 (%struct.__FILE_s*, i64, i32)*, 
i8*, i64, %struct.__FILE_s*, %struct.__FILE_s*, 
i32, i32, i64, i16, i8, i8, i32, i32, i8*, 
i64, i8*, i8*, i8*, i64, i64 }

in some IR files, but was compiled as

%struct.__FILE_s = type { i32, i8*, i8*, 
i32 (%struct.__FILE_s*)*, i8*, i8*, i8*, i8*, 
i64 (%struct.__FILE_s*, i8*, i64)*, 
{}*, 
i64 (%struct.__FILE_s*, i64, i32)*, 
i8*, i64, %struct.__FILE_s*, %struct.__FILE_s*, 
i32, i32, i64, i16, i8, i8, i32, i32, i8*, 
i64, i8*, i8*, i8*, i64, i64 }

in other source files. The only difference between these two IR structs is that a function pointer type field in the first form is replaced by {}* instead of its complete type. Could anyone tell me why this happens and how to disable the {}* replacement?

Answer 1

It's a known bug in Clang .

I don't have any idea how to work-around it, though, other than building Clang yourself and applying the patch discussed at that bug (but be aware that patch was not committed for a reason).

Answer 2

For a simpler example of what is happening here I can do the following:

struct thing;
int do_work(struct thing *to_this);

And the compiler doesn't know the type of thing but can use this in a header file because all it cares is the size of the operand (it's a pointer, so that will be pointer length bytes no matter what it's pointing to).

The same thing appears to be happening in the musl c library. In some compilation units the entire type is defined and in others where it doesn't need access to the specific type the only thing which is known is that it is a pointer.

The fix is easy, rather than forward declaring the type include the header file with the definition of the full type. DON'T DO THIS. You are increasing compile time by doing this and probably worse increasing the bloat of a final executable. Exactly the thing which musl is written to avoid. If the compilation unit doesn't care about the full type then it won't know about the full type. But everything will still work correctly.