Re: Padding vfunc tables for less abi breakeage.

[Murray Cumming <murrayc murrayc com>]

On Thu, 2005-01-06 at 18:21 -0500, Carl Nygard wrote:
> On Thu, 2005-01-06 at 16:20 -0600, Bryan Forbes wrote:
> > 	Murray and I were going over some technicalities of the new Gtkmm
> > release and I was wondering why we couldn't have default signal handlers
> > (virtual methods) for new signals on old classes.  It turns out that
> > this will make the vtable for that class bigger which will kill ABI
> > compatibility.  Maybe you knew this, maybe you didn't.  That's not the
> > point.  My question is this: Should we pad classes with fake virtual
> > functions (like gtk+ does in some places) so we don't break ABI when we
> > add new default signal handlers for releases such as this?  Murray said
> > some may be opposed because of the size of the objects would get a bit
> > bigger, but I'd like to hear some discussion on this.  We're not sure if
> > this would even be possible.  Any advice/comments are welcome.  Thanks
> > in advance!
> > 
> > P.S.  If this is a good idea or even feasible, we won't start doing it
> > until the next release cycle, so don't worry about ABI compatibility
> > this cycle.
> 
> There's a strong possibility that I don't understand this fully, so be
> critical:
> 
> Supposing you pad with dummy signal handlers:
> a) how do you know what arguments the dummy should take, and does the
> argument values affect the size of the vtable entries (doubt it).

I doubt it too, but I'd like to be sure.

> b) assuming the argument list doesn't matter, you are still changing the
> API and the dummy handler is going away, which should affect the
> version-info major:minor:micro as +1:0:0 for ld.  Wouldn't this have the
> same effect as breaking ABI?

It's not really changing ABI or API if the method is called
padding_dont_use_this_ever_wemeanit().

We change the .so version how and when we like, based on whether
applications really need to be rebuilt (never during a stable series). 

> c) Can you rely on the compiler keeping the order of the vtable
> consistent in the face of changing the function name?  If the compiler
> re-orders stuff, then there's no way to keep the vtable sane between
> versions.

Interesting question.

> d) What about debugging if your app was build against 2.8.x but running
> against 2.8.x+N?  How is the vtable info in your app-side classes going
> to jive with the runtime lib version, and is gdb going to have a
> seizure?

We are talking about a comparison of 2.10.x with 2.12.x. But anway, the
whole point is that we will never change the size of the vtable, and we
will never change a function that is actually used. So I don't think
that gdb will have a problem.

> My gut feeling is that vtable issues are a compiler-dependent keep-your-
> grubby-mits-off kind of thing, but of course, I could be wrong...

Possibly. We might need to ask on the C++ newsgroup.

> I guess some simple experiments would be in order.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com