Re: [PATCH V2 2/3] Remove VLAIS usage from gadget code

[Behan Webster <behanw@converseincode.com>]

On 12-12-03 12:57 PM, Sebastian Andrzej Siewior wrote:
> On Thu, Nov 01, 2012 at 09:21:16AM +0200, Felipe Balbi wrote:
>> then we can merge to net tree and handle the conflicts when merging to
>> Linus, that'd be fine by me as long as people know how to solve the
>> conflict properly ;-)
> Felipe please drop this patch. I don't like this VLAIS patch and its
> macro magic. I support the goal of compiling the kernel with clang but I
> don't think that this is appropriate. Davem has also his problems with
> the netfilter part so I am no the only one.
You are definitely not the only one. :)

But that's okay. The idea is to find an alternative that works for 
everyone. It was the first attempt, which didn't work out. <shrug>

> *I* think the gadget part of the kernel is something most people won't
> use so it won't show up.
> Anyway, please drop this completely I try to think of something sane.
He actually didn't take the patch. He was asking the netfilter team to 
take it, and they didn't want to. Fair enough.

However, in order to approximate what gcc is doing in code, obviously 
some math is required. The thought was that macros would hide the worst 
of it, trying not to obfuscate what was actually being done.

One of the project members came up with this alternative. How about 
something like this? Less math, though more string pasting. When 
compiled, the unused variables get optimized away. Otherwise the memory 
packing is identical to using VLAIS in gcc.

#define vla_struct(structname) size_t structname##__##next = 0
#define vla_struct_size(structname) structname##__##next

#define vla_item(structname, type, name, n) \
         type * structname##_##name; \
         size_t structname##_##name##__##pad = \
                 (structname##__##next & (__alignof__(type)-1)); \
         size_t structname##_##name##__##offset = \
                 structname##__##next + structname##_##name##__##pad; \
         size_t structname##_##name##__##sz = n * sizeof(type); \
         structname##__##next = structname##__##next + \
                 structname##_##name##__##pad + 
structname##_##name##__##sz;

#define vla_ptr(ptr,structname,name) structname##_##name = \
(typeof(structname##_##name))&ptr[structname##_##name##__##offset]


Then you can do something like this that looks vaguely struct-like:

         vla_struct(foo);
                 vla_item(foo, char,  vara, 1);
                 vla_item(foo, short, varb, 10);
                 vla_item(foo, int,   varc, 5);
                 vla_item(foo, long,  vard, 3);
         size_t total = vla_struct_size(foo);
         char buffer[total];

         vla_ptr(buffer, foo, varc);
         foo_varc = 1;

I've been profiling some sample code around this implementation 
comparing it between compilers, and it approximates the code size and 
speed of using VLAIS in gcc (especially with -O2). It actually performs 
better than the previously proposed macros.

But certainly if anyone has a solution which works for everyone, then 
I'm more than happy to adopt it. The LLVM community has made quite a few 
changes in order to help get Linux working with clang. However, VLAIS is 
not something they are willing to accept (for various reasons). There 
are other patches to LLVM that are still working their way upstream that 
are required to be able to compile Linux as well.

As far as I've been told (though I have been unable to verify), Variable 
Length Arrays In Structs (VLAIS) is a feature which made it into gcc 
along with nested functions by the work on the Ada frontend. By 
contrast, the C99 standard specifies Variable Length Arrays (outside of 
structs) and Flexible Array Members (essentially zero-length arrays at 
the end of a struct), and as such both are supported by gcc and clang.

The LLVMLinux project is a meta-project between the LLVM and Linux 
communities trying to get the toolchain from one working with the code 
from the other.  The LLVMLinux project isn't trying to replace, nor 
break gcc (in fact all the project's kernel patches are tested with gcc 
as well). The idea is to bring another toolchain and set of tools to the 
table and the kernel community.

Behan

-- 
Behan Webster
behanw@converseincode.com