[LLVMdev] A new mechanism to compiler kernel modules using llvm: Defer type evaluation in clang?

Jovi Zhang bookjovi at gmail.com
Mon Apr 29 07:13:12 PDT 2013


On Mon, Apr 29, 2013 at 9:21 PM, Joshua Cranmer 🐧 <Pidgeot18 at gmail.com> wrote:
> On 4/29/2013 7:32 AM, Jovi Zhang wrote:
>>
>> The case I really want to solve is some kernel change cause ko must need
>> to recompile, like data structure field offset changed in new kernel, this
>> will make offset mismatch between new kernel and old ko. This is the reason
>> why I want to delay type structure evaluation into install time in Clang, In
>> theory, ko compiled now could work in 10 years later whatever how kernel
>> changes.
>
>
> This kind of fix is not possible with LLVM IR right now and generally not
> possible with C code ever unless you make a lot of simplifying assumptions.
> Note that, for example, offsetof and sizeof are resolved to a constant by
> Clang before they are ever lowered to LLVM IR in the first place. Also, the
> way that structs are referenced in LLVM IR do not satisfy binary
> compatibility: a struct is lowered to a sequence of its constituent members
> accessed by their index and not be a given name. This means that inserting a
> member into the struct invalidates the IR.
>
We arrived the key part: offsetof and sizeof are resolved to a
constant by Clang before
they are lowered to LLVM IR, so that's the main reason why there have
a high-level IR file except
LLVM IR file, that high-level IR file contain unresolved structure
field reference info and unresolved
sizeof, that high-level IR file "link" with kernel header ABI file
which contain structure offset and sizeof info,
then generate to LLVM IR file, this is the design picture.

I don't want to change LLVM IR format, I'm just thinking on hack Clang
to output that high-level IR file without
resolved offset/sizeof info, how about this sounds?




More information about the llvm-dev mailing list