Skip to content

Latest commit

 

History

History
52 lines (44 loc) · 2.51 KB

TODO.org

File metadata and controls

52 lines (44 loc) · 2.51 KB

Efficiency

Move to a decent hash?

Currently, there are two distinct classes of hashtable used in libctf:

  • ctf_hash hashes, used for hashes of data read from CTF sections only. These do not support element deletion and have a fixed maximum size, but have a reasonably good hash function. They are fundamental to the performance of CTF in normal operation (when the hashes indeeed do not change in size).
  • handrolled dtd hashes, used for the ctf_dthash and ctf_dvhash, i.e. for hashes of dynamic data in CTF files under construction. These support deletion (very crudely) but have a fixed bucket count (sigh) and in the case of ctf_dthash have an astonishingly crude hash function, which nonetheless probably works.

The latter class of hash has two instances at present, which share no code at all. This is disgusting. Their deletion support is also crude in the extreme and very slow – though as it is only used when ctf_discard() is called, and that is only called on the occasion of a type error, this is probably not important.

adapt to endianness changes

Reliability

Add a testsuite.

OpenSolaris doesn’t come with one, as far as I can tell.

It is true that the only fundamental question is whether dwarf2ctf and dtrace work, and the latter has a testsuite and the former is itself a pretty effective testsuite by virtue of the sheer volume of data it must chew through — but the dtrace testsuite is not publically available, and waiting twenty minutes to see if you’ve introduced a bug is terribly tiresome.

Add a feature flag system to allow backwardly-incompatible changes.

Right now we have no way to add extra validation because existing codebases might be broken (and have to revert one commit on every release branch as a consequence). Add a feature-flag system to allow codebases to certify that they are ready for such changes in a fine-grained manner.

validate all type IDs added

Right now, we do not validate type IDs passed in (e.g. for types containing references to other types) unless we need the types for some other purpose in the addition function. So you can pass in garbage, and cause all sorts of chaos on load. We shuld validate the damn things. Yes, this stops people adding a forward before adding the thing it is a forward to, but nobody should be doing anything so crazy.

Features

Add function-signature mapping

Required for typed args in FBT and systrace.

Minor

Refactor second init_types() loop

Most of the entries can be collapsed to one.