I would like to work on bug ID 6495166 Synopsis  ::confusion over CTF_MAX_TYPE
Category:Subcategory  utility:text 
Brief Description    CTF_MAX_TYPE is:

#define CTF_MAX_TYPE    0xffff

But 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 
 252          * fake entries to fill the holes, or we won't be able to 
 253          * the tree from the written data.
 254          */
 255         if (++b->nptent < CTF_TYPE_TO_INDEX(tp->t_id)) {
 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 everything
wrongly, giving rise to confusing symptoms such as that seen in:

6314239 ctfmerge finds duplicate types when it sees dwarf output from Sun C 

We should probably fix MAX_TYPE to reflect reality. We should also make the 
more 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 to

get the fix done in a week.


My SCA number is OS0146

Thanks & Regards
Amrita University
1st Year Computer Science Engineering

Post ads for free - to sell, rent or even buy.www.yello.in
-------------- next part --------------
An HTML attachment was scrubbed...

Reply via email to