[LLVMdev] Bytecode file bugs / doc bugs

Robert Mykland robert at ascenium.com
Mon Aug 16 13:49:49 PDT 2004


Dear Reid and Chris,

I thought I should send this to the list in case anyone else is struggling 
to interpret bytecode files with the new docs.

(1)     First a bug I already mentioned to Reid.  Unlike the other new 
module headers module 0x01 still uses the old 32-bit and 32-bit format 
instead of the new 5-bit and 27-bit format.  Thus the first module in the 
file will be 0x00000001 followed by a 32-bit size.

(2)     Though it states in the docs that module size numbers do not 
include padding bytes, they often do.  Here's an incomplete list of which 
do and which don't:

module 0x01 includes align bytes
GTP block size does not include align bytes
module global info does
function definitions sometimes do and sometimes don't
compaction tables do not
instruction list -- unknown
function symbol table does not

(3)     In Reid's documentation, his "opcode" link is bad.  His doc does 
not yet contain an opcode section.  Presumably this would contain the info 
from the include file Instruction.def.

(4)     Something is messed up about the symbol table definitions.  The 
number of entries and the type referred to by the symbol are correct, then 
there is a third byte that was either a zero or a one in my simple 
test.  This third byte is not described in the docs I don't believe.  Then 
there is the size byte and the string.

(5)     Labels used to have their own type.  If this is still the case, its 
not discussed in Reid's document.  It looks like the new type slot for 
label is 12, the same as raw function.  Presumably this would be the secret 
type slot between the last primitive type (11) and the new start of the 
defined types table (13).

If I were sorting these into bugs vs. doc changes for 1.31, I would fix #1, 
#2, and possibly #4 in the code depending on what the byte is used for.

It might be a really good bug hunting expedition before each release to 
decode a few bytecode files by hand.  In my experience this is the only way 
to get physical protocols like this right.

Hope this helps!

Thanks again to Reid for the great docs and to Chris and crew for the whole 
LLVM shebang.

Regards,

-- Robert.


Robert Mykland               Voice: (831) 462-6725
Founder/CTO                   Ascenium Corporation 





More information about the llvm-dev mailing list