[Mono-list] Unknown heap type?

[Serge]

> I guess I need to know their
> format anyway, if their ID is lower than one of the currently used
> tables IDs,

For their format and IDs see my metadata lib:
http://mono.eurosoft.od.ua/pet.tar.gz

There is MD schema file that I use for code generation, build/srcgen/data/md-schema.xml
(hopefully, it's self descriptive enough to be useful :-)

It seems that these tables only generated in the IDE when debugging (as well as ENC* tables).
Not sure right now how to produce #- stream with the command-line tools (csc, vbc), except
for the older version of J# that always generates this stream instead of #~.


Sergey


----- Original Message -----
From: "Paolo Molaro" <lupus@ximian.com>
To: <mono-list@ximian.com>
Sent: Tuesday, August 20, 2002 12:31 PM
Subject: Re: [Mono-list] Unknown heap type?


> On 08/19/02 Serge wrote:
> > It's indeed uncompressed data stream, it's mentioned briefly in Part II, 23.2.2
> > "Some compilers store metadata in a #- stream, which holds an uncompressed, or non-optimized, representation of metadata tables;
> > this includes extra metadata "pointer" tables."
> >
> > Those pointer tables are:
> >     FieldPtr
> >     MethodPtr
> >     ParamPtr
> >     EventPtr
> >     PropertyPtr
> >     TypeTyPar
> >     MethodTyPar
> >
> > There are also ENCLog, ENCMap tables, not sure what it is.
> > The stream is pretty straight-forward to reverse-engineer,
> > but I don't think it's useful to add support for the stream.
>
> Well, I'm not even considering it until I can create such a stream with
> a command-line tool. I was wondering if the *Ptr table are something
> like the token pointers I wanted to use to implement the runtime use of
> types created with Reflection.Emit, like I proposed a while ago on the
> list.
> Anyway, if the #- is just like the #~ stream only with the columns in
> the tables uncompressed, it will be easy to support it (i.e. can I just
> ignore the existance of the *Ptr tables? I guess I need to know their
> format anyway, if their ID is lower than one of the currently used
> tables IDs, since the metadata tables format was designed without
> thinking about compatibility with future versions...).
>
> Thanks for the info.
>
> lupus
>
> --
> -----------------------------------------------------------------
> lupus@debian.org                                     debian/rules
> lupus@ximian.com                             Monkeys do it better
>