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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 4 Dec 2012 23:24:38 +0100
From:	Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
To:	Behan Webster <behanw@...verseincode.com>
Cc:	Felipe Balbi <balbi@...com>, davem@...emloft.net,
	linux-usb@...r.kernel.org, netfilter-devel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Compiling the Linux Kernel with Clang/LLVM 
	<llvmlinux@...ts.linuxfoundation.org>
Subject: Re: [PATCH V2 2/3] Remove VLAIS usage from gadget code

On Mon, Dec 03, 2012 at 07:57:33PM +0100, Behan Webster wrote:
> 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.

Why hide? The thing that is done here is setting up pointers and keep this
struct as a container. It is never used again, just freed. Therefore I would
suggest to remove and do something different.

> 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 prefer to try to rewritte the code in the gadget in a different manner
before using macro magic. I guess most people around here think that extensive
usage of macros equals giving a gun to a chimpanzee. It may work for a while
and may even look cute in the eye of the gun sponsor. However once it fires…

> 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.

I'm not concerned about speed here. This is an one time setup.

> 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,

That is nice to hear. Besides gcc there is the icc.

> VLAIS is not something they are willing to accept (for various
> reasons). There are other patches to LLVM that are still working
Is this not described in C99 6.7.2.1p16?

> their way upstream that are required to be able to compile Linux as
> well.

I hope the other are "simple" to get in :)

> 
> Behan
> 

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/