Stephen Kell

It might be reasonable to make bigallocs for our memtables and any other huge allocations, even though we obviously don't want to hook them into the pageindex. The pageindex itself...

Our own ```__private_malloc``` interface could be extended to do the hooky stuff. This will be easier when we have separated out distinct mallocs (see #21).

Anything we mmap ourselves is also in scope here. It should fall under *some* bigalloc. Should we hook our own mallocs (just differently from how we hook user mallocs)? This...

This comes up when interpreting ELF fields, because and Elf64_Addr (say) should be interpreted differently than an Elf64_Off even though they are both 64-bit unsigneds. One could argue, alternatively, that...

Actually, just using an unmodified 15-bit bigalloc number is neater (thanks Occam), and a 17-bit symidx is probably fine.

At least for the case of inserted casts, this is fixed by ccb6640 which pulls a fix in my CIL fork.

Since uniqtypes are quite pointer-dense, the dynamic reloc info can be quite large. So another optimisation: support a custom reloc format that is optimised for this. There's no excuse for...

Another one: don't generate both symbol hash tables, given that nowadays relf.h can grok the GNU-style hash table.

See also #34 -- getting rid of array types will help a lot. Also, the frame information is a killer because it generates large numbers of minor-variant layouts of a...

To expand on the frame info idea: a BAP tool not too different from the frame info synthesis tool, could analyse use of the stack pointer and addresses derived from...