Hi, Ling Kun:
Firstly, thanks for loongson's effort on this issue. and I have merged
and tested with your patch on current open64 trunk, for open64 bug933 it
does work. Congratulations!
Some comments on this patch:
*). this is a totally undocumented gnu extension, so non-gnu compilers can
only guess the semantics for VLAS from gcc's dump. and it is rarely used,
only appeared in the encryption and some drivers part of the kernel,
alternatively, it can be changed into flexible array members although a
little more complexed. Personally I think even open64 should only provide
limited support, i.e, the VLA can only appeared in the last field of a
struct. If you want support the VLA appeared in the middle, it seems that
you should pay more efforts and no production code support your ideas.
*). It seems that your patch mark the VLAS as -1 for the type_size. I once
tried this way, but I have a look on the C99 standard, it only specifies
array as aggregate with sizeof computed in the run-time, the structures or
member of the structures are not allowed with variably-modified field, see
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
page 105. item 8
So, your patch introduced the structure as the variably-modified type will
make the backend believe struct can be exteneded and the type check will
loose. I am not sure what will happen. Maybe the wgen authors may provide
some comments.
*). for the array-size in the last field of VLAS, it seems the patch does
not include type conversion in the code. So your patch will fail on the
following code:
#include <assert.h>
int f2(int i2){ return i2; }
static void f1(int i1) {
struct VLS{ int a;int ary1[f2(i1)]; } st1,st2;
st1.a = 2;
st1.ary1[1] = i1 + 1;
st2.a = 3;
printf("%d,%d\n",st1.a,st2.a);
printf("%d\n",st1.ary1[1]);
}
int main () {
f1(-2);
return 0;
}
If you have a look at the gcc tree dump, you will see gcc make a careful
handling on the variable size.
*). again since this is a totally undocumented feature, how about passing
the VLAS parameters is not documented. You will have to write some
documents on this issue. Or even make a specification for this behaviour.
More general, you will write a document for this feature for the lazy gnu:)
*). for the code related. Since this is rather big contribution, you can
add the contributor affiliation info in the head of changed files And you
have add some basic fundermental routines to wn.cxx, you can check whether
there are already routines there and re-organize your code to avoid
duplications.
Regards
Gang
On Tue, Jan 3, 2012 at 5:19 PM, Ling Kun <erlv5...@gmail.com> wrote:
> Hi, Gang and Sun:
> I have merged ICT's VLAS patch to open64, the code can work for a
> minimal testcase. Please see the attachment. More testcase following the
> standard is needed, and I am working on it.
>
> To make things done quickly, I modified some of the code, the patch
> in the attachment is only a draft version. I also need more information
> about the x86 kernel building environment to go on. And the patch itself
> need some modification to satisfy the svn trunck commit rules.
>
> My team mate Zhao Hongjian is working on the document. It will take
> him some times to finish.
>
>
> Gang, would you please give me some details about your compile
> command and the .i file after preprocessor. Thanks.
>
> Ling Kun.
>
> The testcase :
> #include <assert.h>
> int f2(int i2){ return i2; }
> static void f1(int i1) {
> struct VLS{ int ary1[f2(i1)]; } st1;
> st1.ary1[1] = i1 + 1;
> assert( st1.ary1[1] == 3);
> }
>
> int main () {
> f1(2);
> return 0;
>
> }
>
>
> On Sun, Jan 1, 2012 at 9:02 PM, Gang Yu <yugang...@gmail.com> wrote:
>
>> Hi, Ling Kun:
>>
>> Glad to hear loongson team has solved this issue! I googled this
>> feature on gnu site, I do not find the relevant documents. Could you please
>> write some documents or elaborate more on your patch?
>>
>> Thanks a lot!
>>
>> Regards
>> Gang
>>
>>
>>
>> 2012/1/1 凌坤 <erlv5...@gmail.com>
>>
>>> 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
>>>
>>>
>>
>
>
> --
> http://www.lingcc.com
>
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
