Hi
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
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 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
compiler
We should probably fix MAX_TYPE to reflect reality. We should also make the
tools
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.
http://bugs.opensolaris.org/view_bug.do?bug_id=6593960
My SCA number is OS0146
Thanks & Regards
Arjun.V
Amrita University
1st Year Computer Science Engineering
_________________________________________________________________
Post ads for free - to sell, rent or even buy.www.yello.in
http://ss1.richmedia.in/recurl.asp?pid=186
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20080104/9c487eda/attachment.html>
