dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Qt.dll verification errors


From: Adam Treat
Subject: Re: [DotGNU]Qt.dll verification errors
Date: Thu, 17 Oct 2002 11:36:19 -0400
User-agent: KMail/1.4.7

Looks like Paolo has patched the reflection/mcs like he said.  I'll rebuild 
mono and mcs and get you a new version of Qt.dll ASAP

Thanks for all of your work Gopal, Rhys!

Adam

On Thursday 17 October 2002 04:11 am, Rhys Weatherley wrote:
> address@hidden wrote:
> > Well it works fine when I compile it with cscc ... The errant
> > code is in Qt.dll in the QT# .debs distro ...
> >
> > http://prdownloads.sourceforge.net/qtcsharp/qtsharp_0.5-1_i386.deb?downlo
> >ad
> >
> > I am unable to test it as I have an old version of QT and am
> > unable to compile qtc ... But the error was reported on ilverify
> > of the Qt.dll
> >
> > I think it is a bug with the image read ? .. viz I'm getting '-1'
> > in member.c but no '.try' in the dissassembled code ...
>
> OK, found it.  Sort of.  I think it's a bug in mcs (sorry guys :-) ).
>
> The ECMA spec says that the "DataSize" member of an exception
> block should be "n * 12 + 4" for a tiny format block, or "n * 24 + 4"
> for a fat format block.  Qt.dll appears to have "n * 24" instead
> in the fat format header.  This causes pnet to drop sections because
> it thinks that they are "truncated", which technically they are.
>
> Pnet's behaviour appears to be consistent with MS'es compiler.
> Although I admit my version of csc is a little old.  Weird thing
> is, MS'es diassembler can handle the qtsharp code.  Maybe their
> range checking isn't all that great and so they process it through
> sheer dumb luck?
>
> Mono appears to handle both correct and incorrect formats through
> dumb luck also.  Around line 1500 of mono/metadata/metadata.c:
>
>     mh->num_clauses = is_fat ? sect_data_len / 24: sect_data_len / 12;
>
> If the value is "n * 24" or "n * 24 + 4", the "+ 4" will be
> truncated off and Mono will do the right thing.
>
> So, in summary, cscc-compiled code appears to be ECMA-compatible and
> should work on both pnet and Mono just fine, but mcs-compiled code
> won't work on pnet because my range-checking is a lot stricter.
> Unless I've missed something obvious, of course.  I'm willing to
> be convinced that I'm wrong.
>
> I could add a "mcs bug filter" to pnet I suppose, but it would
> probably be better for mcs to be fixed to generate ECMA-compatible
> exception blocks.
>
> Cheers,
>
> Rhys.
> _______________________________________________
> Developers mailing list
> address@hidden
> http://www.dotgnu.org/mailman/listinfo/developers



reply via email to

[Prev in Thread] Current Thread [Next in Thread]