Yes, here blk is the actual arguments segment, the call stack is as
follows, it will merge blk to its base ".SP"
#5 0x558a980d in Allocate_Space (base=0x80b3d5c, blk=0x80b3c54,
lpad=0, rpad=0, maxsize=2147483647)
at
/export/home/zhuqing/trunk/objdir/osprey/../../osprey/be/com/data_layout.cxx:655
#6 0x558a9fd3 in ST_Block_Merge (block=0x80b3d5c, sym=0x80b3c54,
lpad=0, rpad=0, maxsize=2147483647)
at
/export/home/zhuqing/trunk/objdir/osprey/../../osprey/be/com/data_layout.cxx:754
#7 0x558aa434 in Merge_Fixed_Stack_Frame (SP_baseST=0x80b3d5c,
FP_baseST=0x80b3d88)
at
/export/home/zhuqing/trunk/objdir/osprey/../../osprey/be/com/data_layout.cxx:2181
#8 0x558acaac in Calculate_Stack_Frame_Sizes (PU_tree=0x90fcde8)
Thanks
zhuqing
在 2011年4月12日 下午1:38，Sun Chan <sun.c...@gmail.com> 写道：
> this is a stack variable isn't it. The data layout for this is dones
> elsewhere.
> Sun
>
> 2011/4/12 朱庆 <zqing1...@gmail.com>:
>> Hi Sun,
>>
>> For above test case the error place sym_class of blk is CLASS_BLOCK
>> but not CLASS_FUNC, so only assert on CLASS_FUNC will not work.
>> The dump_st of blk is:
>> Actual_Arg_StkSeg <2,1> Block (#13570)
>> Address: 0(.SP<2,7>)
>> Flags: 0x00000000, XLOCAL
>> Sclass: UNKNOWN
>> size 0, align 4, flags 0x0000, section 0, scninfo 0
>>
>> How do you think?
>>
>> Thanks
>> zhuqing
>>
>> 2011/4/11 Sun Chan <sun.c...@gmail.com>:
>>> looks fine to me.
>>> BTW, if sym_class is FUNC, you should never see it in this routine.
>>> May be you should assert that.
>>> sun
>>>
>>> On Mon, Apr 11, 2011 at 6:25 PM, 朱庆 <zqing1...@gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> Can gatekeeper help review this fix?
>>>>
>>>> The problem is that for expr TY_kind(ST_type(blk)), the ty_idx for blk
>>>> is invalid if the sym_class is CLASS_FUNC or CLASS_BLOCK,CLASS_NAME.
>>>>
>>>> svn diff for r3492:
>>>> Modified: trunk/osprey/be/com/data_layout.cxx
>>>> ===================================================================
>>>> --- trunk/osprey/be/com/data_layout.cxx 2011-02-24 22:51:04 UTC (rev 3491)
>>>> +++ trunk/osprey/be/com/data_layout.cxx 2011-02-25 09:58:56 UTC (rev 3492)
>>>> @@ -652,7 +652,7 @@
>>>> INT64 size;
>>>> INITO_IDX ino_idx;
>>>> // if blk is variable length struct, its size should be inito size.
>>>> - if (TY_kind(ST_type(blk)) == KIND_STRUCT && (ino_idx =
>>>> Find_INITO_For_Symbol(blk)) != 0)
>>>> + if (TY_kind(ST_type(blk)) == KIND_STRUCT && (ino_idx =
>>>> Find_INITO_For_Symbol(blk)) != 0 && INITV_kind(INITO_val(ino_idx)) ==
>>>> INITVKIND_BLOCK)
>>>> {
>>>> size = Get_INITO_Size(ino_idx);
>>>> Is_True(size >= ST_size(blk),("%s's inito size smaller than
>>>> ST_size",ST_name(blk)));
>>>>
>>>> Here is the case, may need to enlarge file number to reproduce:
>>>>
>>>> n=1
>>>> while [ $n -lt 2500 ]
>>>> do
>>>> echo "Processing $n"
>>>> echo "void myfunc$n(){}" > file$n.c
>>>> opencc -Ofast -c -o file$n.o file$n.c
>>>> n=`expr $n + 1`
>>>>
>>>> done
>>>>
>>>> opencc -Ofast -shared -o a.so *.o
>>>>
>>>> The fix is:
>>>> Index: be/com/data_layout.cxx
>>>> ===================================================================
>>>> --- be/com/data_layout.cxx (revision 3537)
>>>> +++ be/com/data_layout.cxx (working copy)
>>>> @@ -652,7 +652,10 @@
>>>> INT64 size;
>>>> INITO_IDX ino_idx;
>>>> // if blk is variable length struct, its size should be inito size.
>>>> - if (TY_kind(ST_type(blk)) == KIND_STRUCT && (ino_idx =
>>>> Find_INITO_For_Symbol(blk)) != 0 && INITV_kind(INITO_val(ino_idx)) ==
>>>> INITVKIND_BLOCK)
>>>> + if ( ST_class(blk) == CLASS_VAR &&
>>>> + TY_kind(ST_type(blk)) == KIND_STRUCT &&
>>>> + (ino_idx = Find_INITO_For_Symbol(blk)) != 0 &&
>>>> + INITV_kind(INITO_val(ino_idx)) == INITVKIND_BLOCK )
>>>> {
>>>> size = Get_INITO_Size(ino_idx);
>>>> Is_True(size >= ST_size(blk),("%s's inito size smaller than
>>>> ST_size",ST_name(blk)));
>>>>
>>>> Thanks Michael Lai point out the issue and provide the case!
>>>>
>>>> Thanks
>>>> zhuqing
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Xperia(TM) PLAY
>>>> It's a major breakthrough. An authentic gaming
>>>> smartphone on the nation's most reliable network.
>>>> And it wants your games.
>>>> http://p.sf.net/sfu/verizon-sfdev
>>>> _______________________________________________
>>>> Open64-devel mailing list
>>>> Open64-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>>>
>>>
>>
>
------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
