Thanks. we also wish could get input from the original wgen authors, it is
leaving an unsupported feature for VLA and then compiler asserts. In order
to avoid duplication of effort, we wish learn from the seniors and then we
can go ahead or make workaround.
Regards
Gang
On Sat, Dec 31, 2011 at 10:42 AM, Sun Chan <sun.c...@gmail.com> wrote:
> 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
