Re: Padding vfunc tables for less abi breakeage.

[Carl Nygard <cjnygard fast net>]

On Fri, 2005-01-07 at 00:43 +0100, Murray Cumming wrote:
> 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().

Yeah, but does the linker know that the app was linked against a shared
lib that had a vfunc named padding_you_better_not_or_else_yeah_you()
which has since disappeared?  Is there anything in the ctor magic that
uses this info? or is the only important thing the number of entries
(well, and the indexes).

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

Well, another point is that now you're locking yourself into supporting
all the old API, without a means to say "that was silly, we're not going
to support that cruft anymore".  And if you do choose to deprecate or
change API across minor numbers, then what was the point of the padding?

I guess the question is, what's more important, freedom to deprecate or
binary compatibility.

Notice I don't have any answers.

Regards,
Carl