3

我使用 Clang 3.3 编译了 MUSL C 库，并转储了生成的 LLVM IR 文件。我发现 FILE 结构

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

被编译为

%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 }

在一些 IR 文件中，但被编译为

%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 }

在其他源文件中。这两个 IR 结构之间的唯一区别是第一种形式的函数指针类型字段被替换为 {}* 而不是其完整类型。谁能告诉我为什么会发生这种情况以及如何禁用 {}* 替换？

4

2 回答 2

2

这是Clang 中的一个已知错误。

不过，我不知道如何解决它，除了自己构建 Clang 并应用在该错误处讨论的补丁（但请注意，补丁未提交是有原因的）。

于 2013-09-11T05:52:44.260 回答
0

对于这里发生的事情的一个更简单的示例，我可以执行以下操作：

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

并且编译器不知道事物的类型，但可以在头文件中使用它，因为它只关心操作数的大小（它是一个指针，所以无论它指向什么，它都是指针长度字节）。

musl c 库中似乎也发生了同样的事情。在某些编译单元中，定义了整个类型，而在其他不需要访问特定类型的编译单元中，唯一已知的是它是一个指针。

修复很简单，而不是前向声明类型包含带有完整类型定义的头文件。不要这样做。这样做会增加编译时间，而且可能会增加最终可执行文件的膨胀。这正是 musl 为了避免而写的。如果编译单元不关心完整类型，那么它就不会知道完整类型。但一切仍将正常工作。

于 2013-09-11T01:10:55.660 回答