Glad to know that you are working on it.
I think this small case is related to it.
Please check it.
--Yuan
----------------------------------------------------------------
/* android 2.2/3 external/elfutils/libebl/eblobjnote.c line 37*/
void ebl_object_note (unsigned int descsz, const char *desc)
{
struct
{
unsigned int os;
unsigned int version[descsz / 4 - 1];
} *tag = (__typeof (tag)) desc;
}
-----------------------------------------------------------------
On Tue, 2012-01-03 at 18:45 +0800, Sun Chan wrote:
> Thx for the clarification. I will try look at the changes. ljx, would
> you take a look also?
> Thx!
> Sun
>
> On Tue, Jan 3, 2012 at 6:40 PM, Ling Kun <erlv5...@gmail.com> wrote:
> > Hi, Sun:
> > Sorry for my confusing expression.
> > This patch is only a private merged patch for Gang Yu's kernel building
> > mail. And is only a draft version patch, which is not intended for SVN
> > submit currently. It is not in Open64 trunck yet.
> >
> > Ling Kun
> >
> >
> > On Tue, Jan 3, 2012 at 6:34 PM, Sun Chan <sun.c...@gmail.com> wrote:
> >>
> >> when did this checkin happened? Did that gone through code review and
> >> checkin review permission?
> >> Sun
> >>
> >> On Tue, Jan 3, 2012 at 6:27 PM, Ling Kun <erlv5...@gmail.com> wrote:
> >> > Hi, Jian-Xin:
> >> > Yes, it support.
> >> >
> >> > I am afraid the comment need to update. We only support last field
> >> > variant-length firstly as the comment says, but after some regression
> >> > test
> >> > for kernel build and debugging, we finally add any field
> >> > variant-length
> >> > support.
> >> >
> >> > Ling Kun
> >> >
> >> >
> >> >
> >> >
> >> > 2012/1/3 Jian-Xin Lai <laij...@gmail.com>
> >> >>
> >> >> From the comments, this patch only supports the case of the last field
> >> >> is variant-length? Does this patch work for the following case:
> >> >> int foo(int x, int y) {
> >> >> struct {
> >> >> int arr1[x];
> >> >> int arr2[0];
> >> >> int arr3[y];
> >> >> } st;
> >> >> st.arr1[0] = st.arr2[0] = st.arr3[0] = 1;
> >> >> printf("%d, %d, %d\n", st.arr1[0], st.arr2[0], st.arr3[0]);
> >> >> }
> >> >>
> >> >> 2012/1/3 Ling Kun <erlv5...@gmail.com>:
> >> >> > 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
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Regards,
> >> >> Lai Jian-Xin
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > http://www.lingcc.com
> >
> >
> >
> >
> > --
> > 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
------------------------------------------------------------------------------
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
