[request-sponsor] Sponsor for Bug ID 6495166 - confusion over CTF_MAX_TYPE
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_TYPE0xBut 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
[request-sponsor] Sponsor for Bug ID 6495166 - confusion over CTF_MAX_TYPE
Hi
I would like to work on bug ID 6495166 Synopsis ::confusion over CTF_MAX_TYPE
Category:Subcategory utility:text
Brief DescriptionCTF_MAX_TYPE is:
#define CTF_MAX_TYPE0x
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
