[fetter-devel] newbie question

[John Morrison]

On Wednesday 19 October 2005 02:13 am, Rayiner Hashem wrote:
> 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++

Oh, the source code uses just about every feature of the language to
its, er, limits, so I should not be at all surprised if this were the
case.  However, while (using grep) I did not find any in the header
files of the source code proper, it includes lots of 3rd party stuff
(license management, STL, etc.).

> 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.

FWIW, I asked Brad King about this (in the course of writing my own
bindings generator), and he explained that due to such considerations
as packing/padding, such sizes were computed/finalized in the
processor-specific backend, so that they are not computable at
GCC-XML's front-end location.

> > 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.

I tried this, but since we land in the debugger before that is done at
the end, it didn't get a chance to run, which is why I turned on the
tracing...  Is there something else I should have traced that would
provide more info?

> 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.

Thanks.  I sent it under separate cover so as not to pollute inboxes
around the globe.

> 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.

OK.  I will go look harder and see if I can find it -- today will
suck, schedule-wise, so I will try to get to it within 24/48 hours or
so.  

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

As they say in geek-speak, I think you have the sign-bit flipped on
that one -- thank *you* for Vzn!

-jm

-- 
==== 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