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

I am not sure this would work. It might be able to handle changes in
structure, but what about changes in the accessor functions?
I also don't see how this would be easier than compiling from source on the
target machine. You still need all the kernel headers on the target machine
because llvm with your patch would need them so that it uses the correct
structure.
The best approach for kernel stuff is to get the source code into mainline,
then the source code will be kept up to date for you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130429/8fabc493/attachment.html>

On Mon, Apr 29, 2013 at 4:40 PM, James Courtier-Dutton
<james.dutton at gmail.com> wrote:
> I am not sure this would work. It might be able to handle changes in
> structure, but what about changes in the accessor functions?
function change is not a big deal, take a example, one function
referenced in ko,
but not exist in new kernel, how could we replace new kernel in this case?
This is not a compatibility issue, because we can add some
compatibility code into new kernel
to maintain old functions for those old ko, so in this case, we still
not need to rebuild ko, right?

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.

> I also don't see how this would be easier than compiling from source on
the
> target machine. You still need all the kernel headers on the target machine
> because llvm with your patch would need them so that it uses the correct
> structure.
We cannot deliver source into target machine. :)
the new method don't need kernel headers in target machine, it just
need a KABI file(whatever binary or text form),
for linking with high-level IR file which compiled by ko source,
output is the low level IR file could accept by llvm,
this is the key design.
> The best approach for kernel stuff is to get the source code into mainline,
> then the source code will be kept up to date for you.
I hope that, but you know, this is not possible to put all hardware
driver and all company private ko into upstream. :)

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.

-- 
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist