Re: Why don't we just FIX the damn vthunk problem?

Re: Why don't we just FIX the damn vthunk problem?

[Mike Stump]

> To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
> Cc: jce2@po.cwru.edu, egcs@cygnus.com
> From: Jason Merrill <jason@cygnus.com>
> Date: 02 Mar 1999 18:35:46 -0800

> >>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

>  > That's an ABI change, isn't it? If the derived class is old code, and
>  > the base class is recompiled, it'll crash - it gets a vtable ptr in
>  > _vptr instead of a vtable array.

> Yep, you're right.  I don't know why we currently set the vptrs before
> calling base and member ctors, but we do.  That's something we could change
> for -fnew-abi.

?  I am seeing:

__4type:
.LLFB4:
        !#PROLOGUE# 0
        save    %sp, -112, %sp
.LLCFI3:
        !#PROLOGUE# 1
        mov     %i0, %l0
        mov     %l0, %o0
        call    __4base, 0
         nop
.LLEHB16:
        sethi   %hi(_vt.4type), %o1
        or      %o1, %lo(_vt.4type), %o0
        st      %o0, [%l0]

struct base {
  virtual ~base() { }
};
 
struct type : public base {
  virtual void m1();
  virtual void m2() { }
};
 
void type::m1() { }
 
int main() {
  type t;
}

in a randomly old compiler.  If someone broke this, this is beyond
bad.  I hope you were thinking of something else.  I tried CVS, and got:

__4type:
.LFB5:
        pushl %ebp
.LCFI14:
        movl %esp,%ebp
.LCFI15:
        pushl %ebx
.LCFI16:
        movl 8(%ebp),%ebx
        pushl %ebx
.LCFI17:
        call __4base
        addl $4,%esp
.LEHB16:
        movl $_vt.4type,(%ebx)
.LEHE16:

Same.  Ok, I'm now confused as you what you meant.  If you meant vbase
pointers, yes, those are part of object layout, and they must be done
before object initialization.

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Mike Stump <mrs@wrs.com> writes:

 >> To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
 >> Cc: jce2@po.cwru.edu, egcs@cygnus.com
 >> From: Jason Merrill <jason@cygnus.com>
 >> Date: 02 Mar 1999 18:35:46 -0800

 >> >>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >>  > That's an ABI change, isn't it? If the derived class is old code, and
 >>  > the base class is recompiled, it'll crash - it gets a vtable ptr in
 >>  > _vptr instead of a vtable array.

 >> Yep, you're right.  I don't know why we currently set the vptrs before
 >> calling base and member ctors, but we do.  That's something we could change
 >> for -fnew-abi.

 > ?

Oops, no, I was misreading the code in emit_base_init.  We set the vptrs
after the base ctors but before the member ctors.  So I once again believe
that passing via the vptr will work; each ctor would do something like

  vtable *tmp = (vtable *) this->A::vptr;
  Base::Base(this, 0);
  this->A::vptr = tmp[1];

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> Same.  Ok, I'm now confused as you what you meant.  If you meant vbase
> pointers, yes, those are part of object layout, and they must be done
> before object initialization.

This is getting complicated. Yes, I was talking about vbase pointers,
as Jason suggested to use them to pass the array of vtables. They get
initialized right when the most-derived class calls all vbase
constructors. Other base classes currently find some vtable in the
vptrs of the vbases :-)

The problem I see is with mixing old and new code. If Jason's approach
is used consistently in the entire hierarchy, it'll work.

Regards,
Martin

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> Oops, no, I was misreading the code in emit_base_init.  We set the vptrs
> after the base ctors but before the member ctors.  So I once again believe
> that passing via the vptr will work; each ctor would do something like
> 
>   vtable *tmp = (vtable *) this->A::vptr;
>   Base::Base(this, 0);
>   this->A::vptr = tmp[1];

It'll work if it is used consistently throughout the hierarchy. If the
derived class is not recompiled, it does

if (in_chrg)
  A::A();   // now this->A::_vptr is initialized
Base::Base(this,0);
this->A::_vptr = __vt_of_most_derived_class

The recompiled base class would find a vtbl in A::_vptr, not a
vtable*. It would then initialize this->A::vptr with a function
pointer, or crash if tmp[n] is out of range. It'll definitely crash if
the base class constructor does call a virtual function.

Regards,
Martin

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

OK, I see the problem.  It hits us when the most derived class is compiled
with an old compiler.

Going back to your earlier idea, I think it would be better to keep in_chrg
and have the vtable list as an additional parameter, for two reasons:

 1) It's also used to control calling op delete in dtors.
 2) If we do, the binary compatibility wrappers can DTRT (or at least as R
    as the current code) instead of aborting.

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> Same.  Ok, I'm now confused as you what you meant.  If you meant vbase
> pointers, yes, those are part of object layout, and they must be done
> before object initialization.

This is getting complicated. Yes, I was talking about vbase pointers,
as Jason suggested to use them to pass the array of vtables. They get
initialized right when the most-derived class calls all vbase
constructors. Other base classes currently find some vtable in the
vptrs of the vbases :-)

The problem I see is with mixing old and new code. If Jason's approach
is used consistently in the entire hierarchy, it'll work.

Regards,
Martin

Re: Why don't we just FIX the damn vthunk problem?

[Mike Stump]

> To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
> Cc: jce2@po.cwru.edu, egcs@cygnus.com
> From: Jason Merrill <jason@cygnus.com>
> Date: 02 Mar 1999 18:35:46 -0800

> >>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

>  > That's an ABI change, isn't it? If the derived class is old code, and
>  > the base class is recompiled, it'll crash - it gets a vtable ptr in
>  > _vptr instead of a vtable array.

> Yep, you're right.  I don't know why we currently set the vptrs before
> calling base and member ctors, but we do.  That's something we could change
> for -fnew-abi.

?  I am seeing:

__4type:
.LLFB4:
        !#PROLOGUE# 0
        save    %sp, -112, %sp
.LLCFI3:
        !#PROLOGUE# 1
        mov     %i0, %l0
        mov     %l0, %o0
        call    __4base, 0
         nop
.LLEHB16:
        sethi   %hi(_vt.4type), %o1
        or      %o1, %lo(_vt.4type), %o0
        st      %o0, [%l0]

struct base {
  virtual ~base() { }
};
 
struct type : public base {
  virtual void m1();
  virtual void m2() { }
};
 
void type::m1() { }
 
int main() {
  type t;
}

in a randomly old compiler.  If someone broke this, this is beyond
bad.  I hope you were thinking of something else.  I tried CVS, and got:

__4type:
.LFB5:
        pushl %ebp
.LCFI14:
        movl %esp,%ebp
.LCFI15:
        pushl %ebx
.LCFI16:
        movl 8(%ebp),%ebx
        pushl %ebx
.LCFI17:
        call __4base
        addl $4,%esp
.LEHB16:
        movl $_vt.4type,(%ebx)
.LEHE16:

Same.  Ok, I'm now confused as you what you meant.  If you meant vbase
pointers, yes, those are part of object layout, and they must be done
before object initialization.

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

OK, I see the problem.  It hits us when the most derived class is compiled
with an old compiler.

Going back to your earlier idea, I think it would be better to keep in_chrg
and have the vtable list as an additional parameter, for two reasons:

 1) It's also used to control calling op delete in dtors.
 2) If we do, the binary compatibility wrappers can DTRT (or at least as R
    as the current code) instead of aborting.

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> Oops, no, I was misreading the code in emit_base_init.  We set the vptrs
> after the base ctors but before the member ctors.  So I once again believe
> that passing via the vptr will work; each ctor would do something like
> 
>   vtable *tmp = (vtable *) this->A::vptr;
>   Base::Base(this, 0);
>   this->A::vptr = tmp[1];

It'll work if it is used consistently throughout the hierarchy. If the
derived class is not recompiled, it does

if (in_chrg)
  A::A();   // now this->A::_vptr is initialized
Base::Base(this,0);
this->A::_vptr = __vt_of_most_derived_class

The recompiled base class would find a vtbl in A::_vptr, not a
vtable*. It would then initialize this->A::vptr with a function
pointer, or crash if tmp[n] is out of range. It'll definitely crash if
the base class constructor does call a virtual function.

Regards,
Martin

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Mike Stump <mrs@wrs.com> writes:

 >> To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
 >> Cc: jce2@po.cwru.edu, egcs@cygnus.com
 >> From: Jason Merrill <jason@cygnus.com>
 >> Date: 02 Mar 1999 18:35:46 -0800

 >> >>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >>  > That's an ABI change, isn't it? If the derived class is old code, and
 >>  > the base class is recompiled, it'll crash - it gets a vtable ptr in
 >>  > _vptr instead of a vtable array.

 >> Yep, you're right.  I don't know why we currently set the vptrs before
 >> calling base and member ctors, but we do.  That's something we could change
 >> for -fnew-abi.

 > ?

Oops, no, I was misreading the code in emit_base_init.  We set the vptrs
after the base ctors but before the member ctors.  So I once again believe
that passing via the vptr will work; each ctor would do something like

  vtable *tmp = (vtable *) this->A::vptr;
  Base::Base(this, 0);
  this->A::vptr = tmp[1];

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Jeffrey A Law]

  In message < 199903011934.LAA12229@Canada.AI.SRI.COM >you write:
  > It is interesting then that introducing a warning in
  > expand_indirect_vtbls_init to accompany the
  > 	      /* We don't have dynamic thunks yet!
  > 		 So for now, just fail silently.  */
  > comment causes more than a half-dozen warnings when compiling
  > libstdc++.
Yes, that is rather disturbing.  Particularly when this this case is supposed
to be extremely rare.

Anyway, thanks for getting the ball rolling on this, it's a long standing
issue that needs to be resolved.


jeff

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> Wouldn't it?  I don't see that.  Seems to me we could do the same thing,
> again copying out the array address on the way up and storing on the way
> down.  The A vptr isn't any more stable than the (hypothetical) B vptr at
> that point.  It's also somewhat more elegant to point to various options
> for the A vptr from the A vptr...
> 
> What am I missing?

That's an ABI change, isn't it? If the derived class is old code, and
the base class is recompiled, it'll crash - it gets a vtable ptr in
_vptr instead of a vtable array. I'm not sure whether it works the
other way 'round, it seems it does (at least as good as it does now).

I much prefer if incompatible code won't link: Replace the implicit
'int in_chrg' with an implicit 'void *vtable_list'. Passing 0 as this
argument indicates we are the most derived class, passing a pointer to
the array is for base classes. If necessary, we can emit the current
implicit-int constructor with delegation to the new ABI as a limited
form of backwards-compatibility, and abort() if this gets called from
a derived class.

Regards,
Martin

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> The static way, which EDG and IBM use, is to write out separate [cd]tor
> vtables along with the normal ones and pass them down into base [cd]tors.
> Obviously, this means you use more space in the executable.
[...]
> Any other ideas?

This is the solution which I'd favour. It would change the calling
convention for constructors of classes with vbases. It would have no
additional costs for other classes, and I doubt that the code to
generate the vtables on the fly is more compact than generating all
the results statically.

Regards,
Martin

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> Not necessarily.  We could set up the [cd]tor vtables in the code
> controlled by the in_chrg parameter, where we actually run the vbase
> [cd]tors.  Then the vbase ctors themselves would wait to set their own
> vtables until the end of the function.

I'm not sure I understand this approach. Consider

class A{virtual void foo();};

class B:virtual A{void foo();};

class C:public B{
  int dummy;
  void foo();
};

When constructing a C instance, the B base constructor needs a vtable
that is only used inside B::B, and only when constructing C instances.
So if you want to statically allocate it, how does B::B know which
table to use, unless C::C passes it as a parameter?

Martin

Re: Why don't we just FIX the damn vthunk problem?

[Mike Harrold]

> 
> >>>>> Jason Eager <jce2@po.cwru.edu> writes:
> 
>  > After all, it's not like a problem that hasn't been solved before...  It
>  > is a BIG problem when a compiler doesn't create valid code no matter how
>  > "obscure" the feature may be (and anyone who wants to enjoy the full
>  > benefits of C++ will probably use multiple inheritence sooner or
>  > later..
> 
> The problem only occurs if you call virtual functions from constructors of
> virtual bases, which seems a bit odd to me, but I agree it should be fixed.
> 
>  > Are there any design documents for egcs? I'll just start working on
>  > implimenting vthunks..but I'd be interested to hear about approaches
>  > that you've thought of for implimenting the vthunks....
> 
> The static way, which EDG and IBM use, is to write out separate [cd]tor
> vtables along with the normal ones and pass them down into base [cd]tors.
> Obviously, this means you use more space in the executable.
> 
> If you don't do this, you need to communicate the offset to the thunks
> somehow.  One way would be to create additional thunks on the stack that
> adjust for the appropriate offset, then jump to the old thunks.  This would
> be the most similar to gcc's non-thunk solution, but it requires support
> for putting code on the stack, like gcc trampolines.  Also, like the
> non-thunk solution, it makes constructors for objects with vbases larger
> and slower.
> 
> Another way, which Microsoft uses, is to store the offset just before the
> vbase subobject so that the thunk can find it and adjust appropriately.
> This adds a bit of space to each vbase subobject.  More importantly,

Ack! Unless I am misreading you, "a bit of space" can be very significant
when you consider word alignment, and 50000 objects, right?

> Microsoft has a patent on it, so it is not an option for us.

1) You can patent something like this? Geez...
2) I guess that makes damn sure this method doesn't get used... :P

/Mike

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 > That's an ABI change, isn't it? If the derived class is old code, and
 > the base class is recompiled, it'll crash - it gets a vtable ptr in
 > _vptr instead of a vtable array.

Yep, you're right.  I don't know why we currently set the vptrs before
calling base and member ctors, but we do.  That's something we could change
for -fnew-abi.

 > I much prefer if incompatible code won't link: Replace the implicit 'int
 > in_chrg' with an implicit 'void *vtable_list'.  Passing 0 as this
 > argument indicates we are the most derived class, passing a pointer to
 > the array is for base classes. If necessary, we can emit the current
 > implicit-int constructor with delegation to the new ABI as a limited
 > form of backwards-compatibility, and abort() if this gets called from a
 > derived class.

Hmm...or we could make vtable_list an additional parameter; that way, we
would still check in_chrg for its old meaning, and use the vtable_list if
available or revert to the old semantics if not.  That would avoid the need
to abort in some situations.

Another thing to consider is that in_chrg is not a boolean for destructors;
it also controls whether to call operator delete.

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> So we have one pointer to pass around, and conveniently there is a
> place in the object that we know will be unset until B::B is run:
> namely, the B vptr (which is shared by C and D).

In my example, there is only one vptr in the entire object: the one of
the virtual base (because the derived class does not define additional
virtuals). So we would have to pass the array of vtables in the vptr
of A. This wouldn't be compatible with the existing convention.

Did I miss something?

Martin

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> So we have one pointer to pass around, and conveniently there is a
 >> place in the object that we know will be unset until B::B is run:
 >> namely, the B vptr (which is shared by C and D).

 > In my example, there is only one vptr in the entire object: the one of
 > the virtual base (because the derived class does not define additional
 > virtuals).  

Oops, forgot that we share vptrs in that case.

 > So we would have to pass the array of vtables in the vptr of
 > A. This wouldn't be compatible with the existing convention.

Wouldn't it?  I don't see that.  Seems to me we could do the same thing,
again copying out the array address on the way up and storing on the way
down.  The A vptr isn't any more stable than the (hypothetical) B vptr at
that point.  It's also somewhat more elegant to point to various options
for the A vptr from the A vptr...

What am I missing?

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> The static way, which EDG and IBM use, is to write out separate [cd]tor
 >> vtables along with the normal ones and pass them down into base [cd]tors.
 >> Obviously, this means you use more space in the executable.
 > [...]
 >> Any other ideas?

 > This is the solution which I'd favour. It would change the calling
 > convention for constructors of classes with vbases.

Not necessarily.  We could set up the [cd]tor vtables in the code
controlled by the in_chrg parameter, where we actually run the vbase
[cd]tors.  Then the vbase ctors themselves would wait to set their own
vtables until the end of the function.

We can make this backward compatible for -fno-new-abi by checking to see if
our vtable has already been set up, and setting it like we do now if not.

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

On Mar  1, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

>> The static way, which EDG and IBM use, is to write out separate [cd]tor
>> vtables along with the normal ones and pass them down into base [cd]tors.
>> Obviously, this means you use more space in the executable.
> [...]
>> Any other ideas?

> This is the solution which I'd favour.

Same here.  I don't like dynamic thunks because on some hosts the
stack is not executable, for security, and it wouldn't be beautiful to
get bug reports about crashes caused by trying to run code out of the
stack.  I myself have spend several weeks wondering why only I got
some failures in the C testsuite before finding out they relied on
trampolines for nested functions and the sysadm had disabled execution
of stack :-(

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> Not necessarily.  We could set up the [cd]tor vtables in the code
 >> controlled by the in_chrg parameter, where we actually run the vbase
 >> [cd]tors.  Then the vbase ctors themselves would wait to set their own
 >> vtables until the end of the function.

 > I'm not sure I understand this approach. Consider

 > struct A{virtual void foo();};

 > struct B:virtual A{void foo();};

 > struct C:public B{
 >   int dummy;
 >   void foo();
 > };

 > When constructing a C instance, the B base constructor needs a vtable
 > that is only used inside B::B, and only when constructing C instances.
 > So if you want to statically allocate it, how does B::B know which
 > table to use, unless C::C passes it as a parameter?

Simply, because C::C does pass it, just in the B vptr slot rather than as a
normal parameter.

In this case, the B constructor vtable is just the B vtable, because B is
not a vbase.  The question is what to do with the A subobject vtable.
During B::B, we need an A vtable that reflects the B virtuals and the C
offsets.  To handle that, we could just set the vtable appropriately from
C::C before calling B::B, and again afterwards.

But when we add another level of inheritance, things get more complicated.

   struct D: public C {
     int dummy2;
     void foo ();
   };

Here, D::D has to communicate alternate vtables to both B::B and C::C.  To
support that, they have to set the A vptr for themselves, so we have to
pass the vtables up.  We can pass them separately or in an array; an array
is more compact.  So we have one pointer to pass around, and conveniently
there is a place in the object that we know will be unset until B::B is
run: namely, the B vptr (which is shared by C and D).  So we stick a
pointer to the array in B::vptr, and the B and C (and D) constructors look
there for it and pull it out before calling their base ctors.  B::B uses
the first element of the array, C the second, D the third and so on.

This is what EDG does.

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Lee Iverson]

In message <u9pv6t91n4.fsf@yorick.cygnus.com> you write:
> >>>>> Jason Eager <jce2@po.cwru.edu> writes:
> 
>  > After all, it's not like a problem that hasn't been solved before...  It
>  > is a BIG problem when a compiler doesn't create valid code no matter how
>  > "obscure" the feature may be (and anyone who wants to enjoy the full
>  > benefits of C++ will probably use multiple inheritence sooner or
>  > later..
> 
> The problem only occurs if you call virtual functions from constructors of
> virtual bases, which seems a bit odd to me, but I agree it should be fixed.

It is interesting then that introducing a warning in
expand_indirect_vtbls_init to accompany the
	      /* We don't have dynamic thunks yet!
		 So for now, just fail silently.  */
comment causes more than a half-dozen warnings when compiling
libstdc++.

>  > Are there any design documents for egcs? I'll just start working on
>  > implimenting vthunks..but I'd be interested to hear about approaches
>  > that you've thought of for implimenting the vthunks....
> 
> The static way, which EDG and IBM use, is to write out separate [cd]tor
> vtables along with the normal ones and pass them down into base [cd]tors.
> Obviously, this means you use more space in the executable.

Given my respect for EDG and annoyance at Microsoft's patent, I'd say
that this is the way to go and would be willing to give it a try.
I'll need some more details on what exactly needs to be done and what I
can read to understand the issues.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 > That's an ABI change, isn't it? If the derived class is old code, and
 > the base class is recompiled, it'll crash - it gets a vtable ptr in
 > _vptr instead of a vtable array.

Yep, you're right.  I don't know why we currently set the vptrs before
calling base and member ctors, but we do.  That's something we could change
for -fnew-abi.

 > I much prefer if incompatible code won't link: Replace the implicit 'int
 > in_chrg' with an implicit 'void *vtable_list'.  Passing 0 as this
 > argument indicates we are the most derived class, passing a pointer to
 > the array is for base classes. If necessary, we can emit the current
 > implicit-int constructor with delegation to the new ABI as a limited
 > form of backwards-compatibility, and abort() if this gets called from a
 > derived class.

Hmm...or we could make vtable_list an additional parameter; that way, we
would still check in_chrg for its old meaning, and use the vtable_list if
available or revert to the old semantics if not.  That would avoid the need
to abort in some situations.

Another thing to consider is that in_chrg is not a boolean for destructors;
it also controls whether to call operator delete.

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> Wouldn't it?  I don't see that.  Seems to me we could do the same thing,
> again copying out the array address on the way up and storing on the way
> down.  The A vptr isn't any more stable than the (hypothetical) B vptr at
> that point.  It's also somewhat more elegant to point to various options
> for the A vptr from the A vptr...
> 
> What am I missing?

That's an ABI change, isn't it? If the derived class is old code, and
the base class is recompiled, it'll crash - it gets a vtable ptr in
_vptr instead of a vtable array. I'm not sure whether it works the
other way 'round, it seems it does (at least as good as it does now).

I much prefer if incompatible code won't link: Replace the implicit
'int in_chrg' with an implicit 'void *vtable_list'. Passing 0 as this
argument indicates we are the most derived class, passing a pointer to
the array is for base classes. If necessary, we can emit the current
implicit-int constructor with delegation to the new ABI as a limited
form of backwards-compatibility, and abort() if this gets called from
a derived class.

Regards,
Martin

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> So we have one pointer to pass around, and conveniently there is a
 >> place in the object that we know will be unset until B::B is run:
 >> namely, the B vptr (which is shared by C and D).

 > In my example, there is only one vptr in the entire object: the one of
 > the virtual base (because the derived class does not define additional
 > virtuals).  

Oops, forgot that we share vptrs in that case.

 > So we would have to pass the array of vtables in the vptr of
 > A. This wouldn't be compatible with the existing convention.

Wouldn't it?  I don't see that.  Seems to me we could do the same thing,
again copying out the array address on the way up and storing on the way
down.  The A vptr isn't any more stable than the (hypothetical) B vptr at
that point.  It's also somewhat more elegant to point to various options
for the A vptr from the A vptr...

What am I missing?

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> So we have one pointer to pass around, and conveniently there is a
> place in the object that we know will be unset until B::B is run:
> namely, the B vptr (which is shared by C and D).

In my example, there is only one vptr in the entire object: the one of
the virtual base (because the derived class does not define additional
virtuals). So we would have to pass the array of vtables in the vptr
of A. This wouldn't be compatible with the existing convention.

Did I miss something?

Martin

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> Not necessarily.  We could set up the [cd]tor vtables in the code
 >> controlled by the in_chrg parameter, where we actually run the vbase
 >> [cd]tors.  Then the vbase ctors themselves would wait to set their own
 >> vtables until the end of the function.

 > I'm not sure I understand this approach. Consider

 > struct A{virtual void foo();};

 > struct B:virtual A{void foo();};

 > struct C:public B{
 >   int dummy;
 >   void foo();
 > };

 > When constructing a C instance, the B base constructor needs a vtable
 > that is only used inside B::B, and only when constructing C instances.
 > So if you want to statically allocate it, how does B::B know which
 > table to use, unless C::C passes it as a parameter?

Simply, because C::C does pass it, just in the B vptr slot rather than as a
normal parameter.

In this case, the B constructor vtable is just the B vtable, because B is
not a vbase.  The question is what to do with the A subobject vtable.
During B::B, we need an A vtable that reflects the B virtuals and the C
offsets.  To handle that, we could just set the vtable appropriately from
C::C before calling B::B, and again afterwards.

But when we add another level of inheritance, things get more complicated.

   struct D: public C {
     int dummy2;
     void foo ();
   };

Here, D::D has to communicate alternate vtables to both B::B and C::C.  To
support that, they have to set the A vptr for themselves, so we have to
pass the vtables up.  We can pass them separately or in an array; an array
is more compact.  So we have one pointer to pass around, and conveniently
there is a place in the object that we know will be unset until B::B is
run: namely, the B vptr (which is shared by C and D).  So we stick a
pointer to the array in B::vptr, and the B and C (and D) constructors look
there for it and pull it out before calling their base ctors.  B::B uses
the first element of the array, C the second, D the third and so on.

This is what EDG does.

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> Not necessarily.  We could set up the [cd]tor vtables in the code
> controlled by the in_chrg parameter, where we actually run the vbase
> [cd]tors.  Then the vbase ctors themselves would wait to set their own
> vtables until the end of the function.

I'm not sure I understand this approach. Consider

class A{virtual void foo();};

class B:virtual A{void foo();};

class C:public B{
  int dummy;
  void foo();
};

When constructing a C instance, the B base constructor needs a vtable
that is only used inside B::B, and only when constructing C instances.
So if you want to statically allocate it, how does B::B know which
table to use, unless C::C passes it as a parameter?

Martin

Re: Why don't we just FIX the damn vthunk problem?

[Jeffrey A Law]

  In message < 199903011934.LAA12229@Canada.AI.SRI.COM >you write:
  > It is interesting then that introducing a warning in
  > expand_indirect_vtbls_init to accompany the
  > 	      /* We don't have dynamic thunks yet!
  > 		 So for now, just fail silently.  */
  > comment causes more than a half-dozen warnings when compiling
  > libstdc++.
Yes, that is rather disturbing.  Particularly when this this case is supposed
to be extremely rare.

Anyway, thanks for getting the ball rolling on this, it's a long standing
issue that needs to be resolved.


jeff

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> The static way, which EDG and IBM use, is to write out separate [cd]tor
 >> vtables along with the normal ones and pass them down into base [cd]tors.
 >> Obviously, this means you use more space in the executable.
 > [...]
 >> Any other ideas?

 > This is the solution which I'd favour. It would change the calling
 > convention for constructors of classes with vbases.

Not necessarily.  We could set up the [cd]tor vtables in the code
controlled by the in_chrg parameter, where we actually run the vbase
[cd]tors.  Then the vbase ctors themselves would wait to set their own
vtables until the end of the function.

We can make this backward compatible for -fno-new-abi by checking to see if
our vtable has already been set up, and setting it like we do now if not.

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Lee Iverson]

In message <u9pv6t91n4.fsf@yorick.cygnus.com> you write:
> >>>>> Jason Eager <jce2@po.cwru.edu> writes:
> 
>  > After all, it's not like a problem that hasn't been solved before...  It
>  > is a BIG problem when a compiler doesn't create valid code no matter how
>  > "obscure" the feature may be (and anyone who wants to enjoy the full
>  > benefits of C++ will probably use multiple inheritence sooner or
>  > later..
> 
> The problem only occurs if you call virtual functions from constructors of
> virtual bases, which seems a bit odd to me, but I agree it should be fixed.

It is interesting then that introducing a warning in
expand_indirect_vtbls_init to accompany the
	      /* We don't have dynamic thunks yet!
		 So for now, just fail silently.  */
comment causes more than a half-dozen warnings when compiling
libstdc++.

>  > Are there any design documents for egcs? I'll just start working on
>  > implimenting vthunks..but I'd be interested to hear about approaches
>  > that you've thought of for implimenting the vthunks....
> 
> The static way, which EDG and IBM use, is to write out separate [cd]tor
> vtables along with the normal ones and pass them down into base [cd]tors.
> Obviously, this means you use more space in the executable.

Given my respect for EDG and annoyance at Microsoft's patent, I'd say
that this is the way to go and would be willing to give it a try.
I'll need some more details on what exactly needs to be done and what I
can read to understand the issues.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

Re: Why don't we just FIX the damn vthunk problem?

[Mike Harrold]

> 
> >>>>> Jason Eager <jce2@po.cwru.edu> writes:
> 
>  > After all, it's not like a problem that hasn't been solved before...  It
>  > is a BIG problem when a compiler doesn't create valid code no matter how
>  > "obscure" the feature may be (and anyone who wants to enjoy the full
>  > benefits of C++ will probably use multiple inheritence sooner or
>  > later..
> 
> The problem only occurs if you call virtual functions from constructors of
> virtual bases, which seems a bit odd to me, but I agree it should be fixed.
> 
>  > Are there any design documents for egcs? I'll just start working on
>  > implimenting vthunks..but I'd be interested to hear about approaches
>  > that you've thought of for implimenting the vthunks....
> 
> The static way, which EDG and IBM use, is to write out separate [cd]tor
> vtables along with the normal ones and pass them down into base [cd]tors.
> Obviously, this means you use more space in the executable.
> 
> If you don't do this, you need to communicate the offset to the thunks
> somehow.  One way would be to create additional thunks on the stack that
> adjust for the appropriate offset, then jump to the old thunks.  This would
> be the most similar to gcc's non-thunk solution, but it requires support
> for putting code on the stack, like gcc trampolines.  Also, like the
> non-thunk solution, it makes constructors for objects with vbases larger
> and slower.
> 
> Another way, which Microsoft uses, is to store the offset just before the
> vbase subobject so that the thunk can find it and adjust appropriately.
> This adds a bit of space to each vbase subobject.  More importantly,

Ack! Unless I am misreading you, "a bit of space" can be very significant
when you consider word alignment, and 50000 objects, right?

> Microsoft has a patent on it, so it is not an option for us.

1) You can patent something like this? Geez...
2) I guess that makes damn sure this method doesn't get used... :P

/Mike

Re: Why don't we just FIX the damn vthunk problem?

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Mar  1, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

>> The static way, which EDG and IBM use, is to write out separate [cd]tor
>> vtables along with the normal ones and pass them down into base [cd]tors.
>> Obviously, this means you use more space in the executable.
> [...]
>> Any other ideas?

> This is the solution which I'd favour.

Same here.  I don't like dynamic thunks because on some hosts the
stack is not executable, for security, and it wouldn't be beautiful to
get bug reports about crashes caused by trying to run code out of the
stack.  I myself have spend several weeks wondering why only I got
some failures in the C testsuite before finding out they relied on
trampolines for nested functions and the sysadm had disabled execution
of stack :-(

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org,computer.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Instituto de Computação, Universidade Estadual de Campinas, SP, Brasil

Re: Why don't we just FIX the damn vthunk problem?

[Martin v. Loewis]

> The static way, which EDG and IBM use, is to write out separate [cd]tor
> vtables along with the normal ones and pass them down into base [cd]tors.
> Obviously, this means you use more space in the executable.
[...]
> Any other ideas?

This is the solution which I'd favour. It would change the calling
convention for constructors of classes with vbases. It would have no
additional costs for other classes, and I doubt that the code to
generate the vtables on the fly is more compact than generating all
the results statically.

Regards,
Martin

Why don't we just FIX the damn vthunk problem?

[Jason Eager]

After all, it's not like a problem that hasn't been solved before...

It is a BIG problem when a compiler doesn't create valid code no matter
how "obscure" the feature
may be (and anyone who wants to enjoy the full benefits of C++ will
probably use multiple inheritence
sooner or later.. This bug HAS to be fixed for this to be considered a
truely viable compiler.

Are there any design documents for egcs? I'll just start working on
implimenting vthunks..but I'd be
interested to hear about approaches that you've thought of for
implimenting the vthunks....

SOMEONE has to fix this, and since this bug has made it impossible to
run several apps that I really
WANT to run, and since no-one here has actually talked about doing
anything about it... I'll start
the momentum.

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Jason Eager <jce2@po.cwru.edu> writes:

 > After all, it's not like a problem that hasn't been solved before...  It
 > is a BIG problem when a compiler doesn't create valid code no matter how
 > "obscure" the feature may be (and anyone who wants to enjoy the full
 > benefits of C++ will probably use multiple inheritence sooner or
 > later..

The problem only occurs if you call virtual functions from constructors of
virtual bases, which seems a bit odd to me, but I agree it should be fixed.

 > Are there any design documents for egcs? I'll just start working on
 > implimenting vthunks..but I'd be interested to hear about approaches
 > that you've thought of for implimenting the vthunks....

The static way, which EDG and IBM use, is to write out separate [cd]tor
vtables along with the normal ones and pass them down into base [cd]tors.
Obviously, this means you use more space in the executable.

If you don't do this, you need to communicate the offset to the thunks
somehow.  One way would be to create additional thunks on the stack that
adjust for the appropriate offset, then jump to the old thunks.  This would
be the most similar to gcc's non-thunk solution, but it requires support
for putting code on the stack, like gcc trampolines.  Also, like the
non-thunk solution, it makes constructors for objects with vbases larger
and slower.

Another way, which Microsoft uses, is to store the offset just before the
vbase subobject so that the thunk can find it and adjust appropriately.
This adds a bit of space to each vbase subobject.  More importantly,
Microsoft has a patent on it, so it is not an option for us.

Any other ideas?

Jason

Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill]

>>>>> Jason Eager <jce2@po.cwru.edu> writes:

 > After all, it's not like a problem that hasn't been solved before...  It
 > is a BIG problem when a compiler doesn't create valid code no matter how
 > "obscure" the feature may be (and anyone who wants to enjoy the full
 > benefits of C++ will probably use multiple inheritence sooner or
 > later..

The problem only occurs if you call virtual functions from constructors of
virtual bases, which seems a bit odd to me, but I agree it should be fixed.

 > Are there any design documents for egcs? I'll just start working on
 > implimenting vthunks..but I'd be interested to hear about approaches
 > that you've thought of for implimenting the vthunks....

The static way, which EDG and IBM use, is to write out separate [cd]tor
vtables along with the normal ones and pass them down into base [cd]tors.
Obviously, this means you use more space in the executable.

If you don't do this, you need to communicate the offset to the thunks
somehow.  One way would be to create additional thunks on the stack that
adjust for the appropriate offset, then jump to the old thunks.  This would
be the most similar to gcc's non-thunk solution, but it requires support
for putting code on the stack, like gcc trampolines.  Also, like the
non-thunk solution, it makes constructors for objects with vbases larger
and slower.

Another way, which Microsoft uses, is to store the offset just before the
vbase subobject so that the thunk can find it and adjust appropriately.
This adds a bit of space to each vbase subobject.  More importantly,
Microsoft has a patent on it, so it is not an option for us.

Any other ideas?

Jason

Why don't we just FIX the damn vthunk problem?

[Jason Eager]

After all, it's not like a problem that hasn't been solved before...

It is a BIG problem when a compiler doesn't create valid code no matter
how "obscure" the feature
may be (and anyone who wants to enjoy the full benefits of C++ will
probably use multiple inheritence
sooner or later.. This bug HAS to be fixed for this to be considered a
truely viable compiler.

Are there any design documents for egcs? I'll just start working on
implimenting vthunks..but I'd be
interested to hear about approaches that you've thought of for
implimenting the vthunks....

SOMEONE has to fix this, and since this bug has made it impossible to
run several apps that I really
WANT to run, and since no-one here has actually talked about doing
anything about it... I'll start
the momentum.