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
Engineering
_________________________________________________________________
Post free property ads on Yello Classifieds now! www.yello.in
http://ss1.richmedia.in/recurl.asp?pid=220
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20080105/01c14037/attachment.html>
