Let me try to understand. You are asking for opinions on whether ope64
should ignore the VLA problem until there is further documentation
and/or evidence of more VLA usage? Until then, workaround that by
changing kernel source?
Sun
On Sat, Dec 31, 2011 at 10:36 AM, Gang Yu <yugang...@gmail.com> wrote:
> Hi, list:
>
> We have some efforts on building and tuning linux kernel on open64, we
> have fixed several bugs and now we have only two building issues and
> several running issues at x86_64 target, O2 level.
>
> linux 2.6.32 as an example, the two building issues are:
>
> A). bug787, Rao Shivarama has submitted a patch, but due to the regression
> filed as bug882, the patch is backed out. This is still a pending issue. My
> personally investigation shows Rao's approach is on the right track, the
> bug882 shows the fix triggers the SSA version verification issues which are
> already known in open64, filed as bug889/891/892. We will continue work on
> it.
>
> B). the Variable Length Array in Structs (VLAS), this is a common issue for
> non-gnu compilers.
>
> clang documents the issue below:
>
> Intentionally unsupported GCC extensions
>
> clang does not support the gcc extension that allows variable-length arrays
> in structures. This is for a few reasons: one, it is tricky to implement,
> two, the extension is completely undocumented, and three, the extension
> appears to be rarely used. Note that clang does support flexible array
> members (arrays with a zero or unspecified size at the end of a structure).
>
>
> I review the failure case of kernel build, the VLAS are not the flexible
> array members(case like this : struct A { int a; int b; char ctx[]} is
> called Flexible array menbers. It is a newly introduced feature c99 or
> later, open64 supports it well.)
>
> VLAS does not appear in linux kernel source code frequently:
>
> lib/libcrc32c.c
> u32 crc32c(u32 crc, const void *address, unsigned int length)
> 43{
> 44 struct {
> 45 struct shash_desc shash;
> 46 char ctx[crypto_shash_descsize(tfm)];
> 47 } desc;
> crypto/testmgr.c
> struct {
> 1432 struct shash_desc shash;
> 1433 char ctx[crypto_shash_descsize(tfm)];
> 1434 } sdesc;
> crypo/hmac.c
> struct {
> 1432 struct shash_desc shash;
> 1433 char ctx[crypto_shash_descsize(tfm)
> ];
> 1434 } sdesc;
>
>
> I just speculate that clang will support kernel build by flexible array
> members. It is not the case,
>
> http://llvm.org/bugs/show_bug.cgi?id=4071
>
> and people claim that they build up kernel with clang, but it is not fully
> functional.
>
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html
>
> as this guy pointed out,
>
> * SELinux, Posix ACLs, IPSec, eCrypt, anything that uses the crypto API -
> None
> of these will compile, due to either an ICE or variable-length arrays in
> structures (don't remember which, it's in my notes somewhere). If it's
> variable-length arrays or another intentionally unsupported GNUtension,
> I'm
> hoping it's just used in some isolated implementation detail (or
> details),
> and not a fundamental part of the crypto API (honestly just haven't had
> a
> chance to dive into the crypto source yet). I'm really hoping it's an
> issue
> in Clang, though, as it's easier for me to hack Clang and I'm trying to
> avoid kernel patches as much as possible.
>
>
> We meet the problem and post it out, we wish we could get input from
> community and go on the kernel building/tuning work to broaden the open64's
> application and improve the code quality.
>
> Thanks.
>
> Regards
> Gang
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Open64-devel mailing list
> Open64-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
