[Top][All Lists]
[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