Re: Padding vfunc tables for less abi breakeage.



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


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

I guess some simple experiments would be in order.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]