Hi, Sun:
I am glad to do that. And now I am trying to merge this patch to Open64 svn
trunck, it is a little complex to try to pick it from the Loongson branch :)
Hoping that a patch that can pass some testcase can be submit in 1-2 days :)
Happy New year.
Ling Kun
------------------ Original ------------------
From: "Sun Chan"<sun.c...@gmail.com>;
Date: Sun, Jan 1, 2012 02:25 PM
To: "Ling Kun"<lkun.e...@gmail.com>;
Cc: "open64-devel"<open64-devel@lists.sourceforge.net>;
Subject: Re: [Open64-devel] Current build status for linux kernel on open64
LingKun,
can you send the changes for VLS (or VLA) to this alias (or send to me
and Yugang privately and we can help review and test out on x86) for
review?
Sun
On Sun, Jan 1, 2012 at 10:14 AM, Ling Kun <lkun.e...@gmail.com> wrote:
> hi, Gang Yu:
> Loongson compiler(based on Open64) team have successfully build MIPS
> Linux kernel 2.6.35, and make it run on Qemu. And we have solved the VLA
> issue, the debug record and patches (based on the Open64 trunck svn r28xx)
> of Loongson teams' work have be sent to Zhu qing.
> If it is possible, we are glad to merge our VLA work to Open64 current
> SVN trunck version.
>
> Ling Kun.
>
>
>
> On Sat, Dec 31, 2011 at 10:45 AM, Gang Yu <yugang...@gmail.com> wrote:
>>
>> 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
>>
>
>
>
> --
> http://www.lingcc.com
>
> ------------------------------------------------------------------------------
> 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------------------------------------------------------------------------------
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
