Hi  I would like to work on bug ID 6495166 Synopsis  ::confusion over 
CTF_MAX_TYPECategory:Subcategory  utility:text  Brief Description    
CTF_MAX_TYPE is:#define CTF_MAX_TYPE    0xffffBut in fact, that doesn't really 
work:#define CTF_TYPE_TO_INDEX(id)           ((id) & 0x7fff) 248         /* 249 
         * There shouldn't be any holes in the type list (where a hole is 250   
       * defined as two consecutive tdescs without consecutive ids), but 251    
      * check for them just in case.  If we do find holes, we need to make 252  
        * fake entries to fill the holes, or we won't be able to reconstruct 
253          * the tree from the written data. 254          */ 255         if 
(++b->nptent < CTF_TYPE_TO_INDEX(tp->t_id)) { 256 257                 
ctt.ctt_name = CTF_TYPE_NAME(CTF_STRTAB_0, 0); 258                 ctt.ctt_info 
= CTF_TYPE_INFO(0, 0, 0); 259                 while (b->nptent < 
CTF_TYPE_TO_INDEX(tp->t_id)) { 260                         
write_sized_type_rec(b, &ctt, 0); 261                         b->nptent++; 262  
               } 263         }When we overflow, we won't catch type holes, and 
end up numbering everythingwrongly, giving rise to confusing symptoms such as 
that seen in:6314239 ctfmerge finds duplicate types when it sees dwarf output 
from Sun C compilerWe should probably fix MAX_TYPE to reflect reality. We 
should also make the toolsmore robust such that they complain loudly as soon as 
we bust the limit.    I don't have the fix ready yet.I'm working on it and hope 
toget the fix done in a 
week.http://bugs.opensolaris.org/view_bug.do?bug_id=6495166 My SCA number is 
OS0146Thanks & RegardsArjun.VAmrita University1st Year Computer Science 
Post free property ads on Yello Classifieds now! www.yello.in
-------------- next part --------------
An HTML attachment was scrubbed...

Reply via email to