[LLVMdev] Re: Bytecode file bugs / doc bugs

[Reid Spencer]

Initial feedback: With the exception of #2, I don't think any of these
things are bugs, just doc discrepancies. I'll provide a more detailed
response later tonight and update the docs to make it clearer on what is
going on. Most of the things you mentioned are a result of planned 1.3
bytecode format changes. You might get some mileage by looking at the
section at the end of the document that describes the 1.2 -> 1.3
changes.

Reid.

On Mon, 2004-08-16 at 13:49, Robert Mykland wrote:
> 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 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040816/6d0332e1/attachment.sig>