[fetter-devel] newbie question

Rayiner Hashem rayiner at gmail.com
Wed Oct 19 06:13:38 UTC 2005


> Short Version: Newbie trying to use verrazano on several MLOC C++ base

:-/

> and getting nil concrete-type-size.

Hmm...

> I will of course attempt to dive
> into the source and figure it out (I have read the documents).  Is
> there anything else I should know that might save some time?

The documentation on the IR and backend are fairly up-to-date, but
there is little documentation for the simplifier. Basically, the code
that handles C++ is at the end of simplifier.lisp, so if the problem
is anywhere its there. I have a hunch that its related to virtual base
classes being present in the inheritence graph. The current Vzn C++
code relies on GCC-XML to compute the sizes of classes so it can use
them for object layout. The problem is that GCC-XML doesn't compute
the sizes of "complicated" classes, specifically those that are the
result of virtual inheritence.

> Is there
> some instrumentation I should turn on to Get A Clue?

The create-binding call takes an optional parameter telling Vzn to
dump all its internals to the terminal. This will dump the IR (pre and
post simplification, I believe), as well as a lot of info about what
Vzn things the class hierarchy looks like.

> Is this a
> surprising enough result that somebody wants the XML file?

Is this particularly surprising? Not really. To tell the truth, the
current C++ layout code is rather simplistic, and is being rewritten.
It works okay for small libraries, but relies too much on GCC-XML to
support certain cases. I don't regret the old code --- I think it was
necessary to build something simple first before building something
"proper", but I'm happy its going away. The new code is a very precise
implementation of the GNU C++ and Visual C++ ABIs, and does all object
and v-table layout itself, so it should fully support virtual
inheritence.

That said, I'm not a big fan of saying "the code is going away so
let's not worry about its bugs". So go ahead and send me the XML file,
and we'll see what we can see. The current version of Vzn's layout
code won't allow access to virtually-inherited members, but it
shouldn't crash either. Also, the XML file could be quite useful in
testing the new layout code.

> I turned on tracing of ANNOTATE-BASE-OFFSETS and CONCRETE-TYPE-SIZE,
> the latter of which seems to be returning a NIL to be added via incf.
> From what I can make out so far, nil is the :initform for the size
> slot of concrete-type.  I guess it's not being set after
> initialize-instance time...  Any hints for obvious places to look or
> routines to trace that might shed some light?

The only thing that sets the slot referred to by concrete-type-size is
the with-concrete-type macro in parser.lisp. It's used for several
node types in handlers.lisp (which is fairly self-explanatory ---
there is one handler function for each IR type). If it doesn't get set
in one of the handler functions (which might happen if the XML node
has no "size" attribute --- Ie: GCC-XML doesn't compute it's size),
then it'll be nil. So I'm pretty sure virtual inheritence is the case
of the problems.

Anyway, thanks for your detailed bug report and your interest in Vzn!

Sincerely,
    Rayiner  Hashem

> ==== John Morrison
> ==== MAK Technologies Inc.
> ==== 10 Fawcett Street, Cambridge, MA 02138
> ==== http://www.mak.com/
> ==== vox:617-876-8085 x115
> ==== fax:617-876-9208
> ==== jm at mak.com
>
>
> _______________________________________________
> fetter-devel mailing list
> fetter-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel
>



More information about the fetter-devel mailing list