|
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.
OK, that makes sense. What we really need, it seems, is two definitions -
one that has this 'external' ID notion, and another one that reflects
the child/parent split. Then we should use the latter to add safety
checks to the CTF tools.
PS external people can't see your comments.
|