[Mono-dev] Cecil bug report and a question

[Jb Evain]

Hi Bjarke,

Bjarke Hammersholt Roune wrote:
> I have taken a look at 0.4.3, and you are correct that it can read and 
> then write the bug-triggering assembly that I attached to my previous 
> bug report without problems. The issue has not been entirely fixed, 
> however. I have attached an assembly that makes Cecil output an invalid 
> assembly. This is using Cecil 0.4.3 - I have not checked the version of 
> Cecil in SVN. Specifically MS peverify gives the following complaint 
> when I run it on the output:
> 
> [IL]: Error: [E:\net\o.exe : Bug::Main][offset 0x00000007] Handler 
> starts in the middle of an instruction.
> 
> As far as I can tell the problem is rather the handler end than the 
> start, but maybe I am wrong (I can't inspect it manually as ildasm does 
> not display what the actual ranges are, probably because in this case 
> the handler is invalid).
> 
> I believe I have tracked the problem down to the following method in 
> CodeWriter.cs:
> 
> int GetLength (Instruction start, Instruction end, Instruction last)
> {
>     return (end == null ? last.Offset + last.OpCode.Size : end.Offset) - 
> start.Offset;
> }
> 
> As far as I have been able to figure out, OpCode.Size is only the size 
> of the opcode itself - it does not include any parameters that follow 
> the opcode. Thus the ending offset is miscalculated in case the last 
> instruction in the method has any parameters, and that instruction is 
> also the last instruction in an exception handler.

Hmm, interesting, I'll have a look at that soon. Thanks for the test case!

> The thing is, I am not sure how ranges are handled in Cecil. I think it 
> works like this: all ranges of instructions are represented as half open 
> intervals [start, end), where start and end are pointers to actual 
> Instructions. start and end can be null if they are past the last 
> instruction. Is this correct?

Yes it is. But we expect that only the end could be pointing after the 
last instruction. If start is null then we have a real problem.

>> Cecil does not preserve the .rsrc (aka Win32 resources) section or the 
>> PE file for the moment. So it saves some place.
>>
> What are the consequences of this other than smaller assemblies?

We can not add stuff like Win32 icons, or any kind of Win32 resources to 
the assembly. Kornél already wrote some stuff to handle that in mcs and 
ilasm, thought I'm not sure I want to include his code which very 
complete, but also kind of large.

Jb