#pragma interface && generating virtual tables (of templates?)

#pragma interface && generating virtual tables (of templates?)

[Carlo Wood]

Hi all,

I have good reasons to believe that #pragma interface, when
added to a header file which contains templates, results
sometimes (constistently, but too complex for me to understand
under what kind of conditions) in certain virtual tables
not to be generated.

Am I correct to think that this would be a bug, because
templates should not be influenced by '#pragma interface'
at all (since they don't generate code by themselfs to
begin with)?

One of the reasons that I think that this must be a bug
in egcs (I still use 1.1.1 release) is that when I *remove*
a fucntion call somewhere it started to link, see
example below - I can't provide a working example because
of the included header files :(.

If one NOT #defines FOOBAR then the code below compiles and
links fine, if you do #define FOOBAR, then I get
(among other undefines):

/home/carlo/c++/egcs.bugs/bug3/ircd.lag.cc:34: undefined reference to `server_sock_dct virtual table'

The problem is also solved by removing the "#pragma interface"
in one of the header files (libr/sock.h).

When excluding the code between #ifdef FOOBAR ... #endif, it compiles
and links fine, as I just said, and I get:

~/c++/egcs.bugs/bug3>nm -C ircd.lag.o | grep server_sock_dct
00000000 W server_sock_dct::~server_sock_dct(void)
00000000 W server_sock_dct::server_sock_dct(int)
00000000 W server_sock_dct type_info function
00000000 W virtual function thunk (delta:-44) for server_sock_dct::~server_sock_dct(void)
00000000 W virtual function thunk (delta:-64) for server_sock_dct::~server_sock_dct(void)
00000010 C server_sock_dct type_info node
00000000 W server_sock_dct virtual table
00000000 W server_sock_dct::ios virtual table
00000000 W server_sock_dct::fd_dct virtual table
00000000 W server_sock_dct::dbbuf_fd_dtct<write_ostream_ct> virtual table
00000000 W server_sock_dct::get_output_stream(void) const

So, by NOT including the call to timer(), it DOES generate code which
it does not generate when I do NOT call timer():

~/c++/egcs.bugs/bug3>nm -C ircd.lag.o | grep server_sock_dct
00000000 W server_sock_dct::server_sock_dct(int)
         U server_sock_dct virtual table
         U server_sock_dct::ios virtual table
         U server_sock_dct::fd_dct virtual table
         U server_sock_dct::dbbuf_fd_dtct<write_ostream_ct> virtual table

Now normally I'd expect that by calling extra code, extra templates
get instantiated (at most), and not that I get LESS generated code.

I understand this is all pretty vague :(, because I can't provide
a working example - but perhaps someone can give me a clue on
whether or not using #pragma interface is deprecated in this case
and/or if I can organize things differently so I won't get undefined
virtual tables all the time :)... Some general story thus.

At the bottom have added some brainstorming :/

Thanks,

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

-----------------------------------------------------------------------------
#include <libr/sys.h>
#include <libr/sock.h>
#include <libr/timing.h>

class server_input_ct : public decode_input_ct {
protected:
  void decode(char *msg, size_t len);
  virtual ostream &get_output_stream(void) const = 0;
  server_input_ct(dbstreambuf_ct *ibuf) : decode_input_ct(ibuf) { }

private:
  void msg_expired(const timer_event_type_ct &expired_at);
};

void server_input_ct::decode(char *msg, size_t len)
{
#ifdef FOOBAR
  struct timeval timeout = { 1, 0 };
  timer(timeout, *this, &msg_expired);
#endif
}

void server_input_ct::msg_expired(const timer_event_type_ct &expired_at)
{
}

class server_sock_dct : public sock_dtct<server_input_ct, write_ostream_ct> {
protected:
  virtual ostream &get_output_stream(void) const { return *((ostream *)NULL); }
};

int main(void)
{
  new server_sock_dct();
}
==============================================================================

More about the header files:

The reason for class server_sock_dct not to be generated (its virtual table
that is) can probably found in the fact that:

/home/carlo/c++/egcs.bugs/bug3/ircd.lag.cc:34: undefined reference to `server_sock_dct::dbbuf_fd_dtct<write_ostream_ct> virtual table'

The hierarchy of the classes is:

class server_sock_dct :
    public sock_dtct<server_input_ct, write_ostream_ct>

sock_dtct<server_input_ct, write_ostream_ct> :
    public iodbbuf_fd_dtct<server_input_ct, write_ostream_ct>, private sockbuf_dbct, virtual public fd_dct

class sockbuf_dbct : virtual public fd_dct

class fd_dct : public node_tct<sbll_node_ct, fd_dct>

class node_tct<sbll_node_ct, fd_dct> : public sbll_node_ct

class sbll_node_ct: private sbll_base_ct

class sbll_base_ct

class iodbbuf_fd_dtct<server_input_ct, write_ostream_ct> :
    public dbbuf_fd_dtct<server_input_ct>, public dbbuf_fd_dtct<write_ostream_ct>, virtual public fd_dct

class server_input_ct : public decode_input_ct

class decode_input_ct : public line_input_ct

class line_input_ct : public read_input_ct

class read_input_ct : public input_ct

class input_ct : virtual public fd_dct

class write_ostream_ct : public write_output_ct, public ostream

class write_output_ct : public output_ct

class output_ct : virtual public fd_dct

class dbbuf_fd_dtct<server_input_ct> : public server_input_ct, virtual public fd_dct

class dbbuf_fd_dtct<write_ostream_ct> : public write_ostream_ct, virtual public fd_dct

(This makes clear I hope why I can't seem to make a small working example).

In other words, when dbbuf_fd_dtct<write_ostream_ct> virtual table
is not generated, then iodbbuf_fd_dtct<server_input_ct, write_ostream_ct> virtual table
is not generated, then sock_dtct<server_input_ct, write_ostream_ct> virtual table
is not generated, then server_sock_dct virtual table is not generated.

There doesn't seem any reason however why dbbuf_fd_dtct<write_ostream_ct> virtual table
is not generated: This class is only derived from write_ostream_ct and
the virtual base class fd_dct - which both are stable classes that have worked
for at least a year now.

Re: #pragma interface && generating virtual tables (of templates?)

[Martin v. Loewis]

> /home/carlo/c++/egcs.bugs/bug3/ircd.lag.cc:34: undefined reference to `server_sock_dct virtual table'
[...]
> Am I correct to think that this would be a bug, because
> templates should not be influenced by '#pragma interface'
> at all (since they don't generate code by themselfs to
> begin with)?

I'd agree this is a bug, at least on the information you provided. Of
course, providing a full bug support (i.e. including preprocessor
output of ircd.lag.ii) shouldn't be that difficult, unless you've
copyright problems.

The virtual table for server_sock_dct should get emitted into
ircd.lag.o. As a work-around, you can probably force this by 
implementing get_output_stream out-of-line.

> I understand this is all pretty vague :(, because I can't provide
> a working example - but perhaps someone can give me a clue on
> whether or not using #pragma interface is deprecated in this case
> and/or if I can organize things differently so I won't get undefined
> virtual tables all the time :)

I'd say #pragma interface is deprecated, period. If you count the
trouble you had with it, don't you agree that it wasn't worth it?
With the new weak and link-once symbols on Linux-ELF, there is hardly
any use for it anymore.

Regards,
Martin

Re: #pragma interface && generating virtual tables (of templates?)

[Carlo Wood]

| I'd say #pragma interface is deprecated, period. If you count the
| trouble you had with it, don't you agree that it wasn't worth it?

It used to be worth it.

| With the new weak and link-once symbols on Linux-ELF, there is hardly
| any use for it anymore.
| 
| Regards,
| Martin

Thank you :).

I deleted all occurances of #pragma interface from my 41 headers,
and the result is:

		   Compile time         Size of resulting
		   on my PPro200        shared library
		   ---------------------------------------
With #pragma       86 s                 1649639 bytes
Without #pragma    86 s                 1663340 bytes

I guess I'll stop using it.

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: #pragma interface && generating virtual tables (of templates?)

[Carlo Wood]

| I'd say #pragma interface is deprecated, period. If you count the
| trouble you had with it, don't you agree that it wasn't worth it?

It used to be worth it.

| With the new weak and link-once symbols on Linux-ELF, there is hardly
| any use for it anymore.
| 
| Regards,
| Martin

Thank you :).

I deleted all occurances of #pragma interface from my 41 headers,
and the result is:

		   Compile time         Size of resulting
		   on my PPro200        shared library
		   ---------------------------------------
With #pragma       86 s                 1649639 bytes
Without #pragma    86 s                 1663340 bytes

I guess I'll stop using it.

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: #pragma interface && generating virtual tables (of templates?)

[Martin v. Loewis]

> /home/carlo/c++/egcs.bugs/bug3/ircd.lag.cc:34: undefined reference to `server_sock_dct virtual table'
[...]
> Am I correct to think that this would be a bug, because
> templates should not be influenced by '#pragma interface'
> at all (since they don't generate code by themselfs to
> begin with)?

I'd agree this is a bug, at least on the information you provided. Of
course, providing a full bug support (i.e. including preprocessor
output of ircd.lag.ii) shouldn't be that difficult, unless you've
copyright problems.

The virtual table for server_sock_dct should get emitted into
ircd.lag.o. As a work-around, you can probably force this by 
implementing get_output_stream out-of-line.

> I understand this is all pretty vague :(, because I can't provide
> a working example - but perhaps someone can give me a clue on
> whether or not using #pragma interface is deprecated in this case
> and/or if I can organize things differently so I won't get undefined
> virtual tables all the time :)

I'd say #pragma interface is deprecated, period. If you count the
trouble you had with it, don't you agree that it wasn't worth it?
With the new weak and link-once symbols on Linux-ELF, there is hardly
any use for it anymore.

Regards,
Martin

#pragma interface && generating virtual tables (of templates?)

[Carlo Wood]

Hi all,

I have good reasons to believe that #pragma interface, when
added to a header file which contains templates, results
sometimes (constistently, but too complex for me to understand
under what kind of conditions) in certain virtual tables
not to be generated.

Am I correct to think that this would be a bug, because
templates should not be influenced by '#pragma interface'
at all (since they don't generate code by themselfs to
begin with)?

One of the reasons that I think that this must be a bug
in egcs (I still use 1.1.1 release) is that when I *remove*
a fucntion call somewhere it started to link, see
example below - I can't provide a working example because
of the included header files :(.

If one NOT #defines FOOBAR then the code below compiles and
links fine, if you do #define FOOBAR, then I get
(among other undefines):

/home/carlo/c++/egcs.bugs/bug3/ircd.lag.cc:34: undefined reference to `server_sock_dct virtual table'

The problem is also solved by removing the "#pragma interface"
in one of the header files (libr/sock.h).

When excluding the code between #ifdef FOOBAR ... #endif, it compiles
and links fine, as I just said, and I get:

~/c++/egcs.bugs/bug3>nm -C ircd.lag.o | grep server_sock_dct
00000000 W server_sock_dct::~server_sock_dct(void)
00000000 W server_sock_dct::server_sock_dct(int)
00000000 W server_sock_dct type_info function
00000000 W virtual function thunk (delta:-44) for server_sock_dct::~server_sock_dct(void)
00000000 W virtual function thunk (delta:-64) for server_sock_dct::~server_sock_dct(void)
00000010 C server_sock_dct type_info node
00000000 W server_sock_dct virtual table
00000000 W server_sock_dct::ios virtual table
00000000 W server_sock_dct::fd_dct virtual table
00000000 W server_sock_dct::dbbuf_fd_dtct<write_ostream_ct> virtual table
00000000 W server_sock_dct::get_output_stream(void) const

So, by NOT including the call to timer(), it DOES generate code which
it does not generate when I do NOT call timer():

~/c++/egcs.bugs/bug3>nm -C ircd.lag.o | grep server_sock_dct
00000000 W server_sock_dct::server_sock_dct(int)
         U server_sock_dct virtual table
         U server_sock_dct::ios virtual table
         U server_sock_dct::fd_dct virtual table
         U server_sock_dct::dbbuf_fd_dtct<write_ostream_ct> virtual table

Now normally I'd expect that by calling extra code, extra templates
get instantiated (at most), and not that I get LESS generated code.

I understand this is all pretty vague :(, because I can't provide
a working example - but perhaps someone can give me a clue on
whether or not using #pragma interface is deprecated in this case
and/or if I can organize things differently so I won't get undefined
virtual tables all the time :)... Some general story thus.

At the bottom have added some brainstorming :/

Thanks,

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

-----------------------------------------------------------------------------
#include <libr/sys.h>
#include <libr/sock.h>
#include <libr/timing.h>

class server_input_ct : public decode_input_ct {
protected:
  void decode(char *msg, size_t len);
  virtual ostream &get_output_stream(void) const = 0;
  server_input_ct(dbstreambuf_ct *ibuf) : decode_input_ct(ibuf) { }

private:
  void msg_expired(const timer_event_type_ct &expired_at);
};

void server_input_ct::decode(char *msg, size_t len)
{
#ifdef FOOBAR
  struct timeval timeout = { 1, 0 };
  timer(timeout, *this, &msg_expired);
#endif
}

void server_input_ct::msg_expired(const timer_event_type_ct &expired_at)
{
}

class server_sock_dct : public sock_dtct<server_input_ct, write_ostream_ct> {
protected:
  virtual ostream &get_output_stream(void) const { return *((ostream *)NULL); }
};

int main(void)
{
  new server_sock_dct();
}
==============================================================================

More about the header files:

The reason for class server_sock_dct not to be generated (its virtual table
that is) can probably found in the fact that:

/home/carlo/c++/egcs.bugs/bug3/ircd.lag.cc:34: undefined reference to `server_sock_dct::dbbuf_fd_dtct<write_ostream_ct> virtual table'

The hierarchy of the classes is:

class server_sock_dct :
    public sock_dtct<server_input_ct, write_ostream_ct>

sock_dtct<server_input_ct, write_ostream_ct> :
    public iodbbuf_fd_dtct<server_input_ct, write_ostream_ct>, private sockbuf_dbct, virtual public fd_dct

class sockbuf_dbct : virtual public fd_dct

class fd_dct : public node_tct<sbll_node_ct, fd_dct>

class node_tct<sbll_node_ct, fd_dct> : public sbll_node_ct

class sbll_node_ct: private sbll_base_ct

class sbll_base_ct

class iodbbuf_fd_dtct<server_input_ct, write_ostream_ct> :
    public dbbuf_fd_dtct<server_input_ct>, public dbbuf_fd_dtct<write_ostream_ct>, virtual public fd_dct

class server_input_ct : public decode_input_ct

class decode_input_ct : public line_input_ct

class line_input_ct : public read_input_ct

class read_input_ct : public input_ct

class input_ct : virtual public fd_dct

class write_ostream_ct : public write_output_ct, public ostream

class write_output_ct : public output_ct

class output_ct : virtual public fd_dct

class dbbuf_fd_dtct<server_input_ct> : public server_input_ct, virtual public fd_dct

class dbbuf_fd_dtct<write_ostream_ct> : public write_ostream_ct, virtual public fd_dct

(This makes clear I hope why I can't seem to make a small working example).

In other words, when dbbuf_fd_dtct<write_ostream_ct> virtual table
is not generated, then iodbbuf_fd_dtct<server_input_ct, write_ostream_ct> virtual table
is not generated, then sock_dtct<server_input_ct, write_ostream_ct> virtual table
is not generated, then server_sock_dct virtual table is not generated.

There doesn't seem any reason however why dbbuf_fd_dtct<write_ostream_ct> virtual table
is not generated: This class is only derived from write_ostream_ct and
the virtual base class fd_dct - which both are stable classes that have worked
for at least a year now.

Re: #pragma interface && generating virtual tables (of templates?)

[Mike Stump]

> From: Carlo Wood <carlo@runaway.xs4all.nl>
> Date: Sun, 21 Feb 1999 02:46:18 +0100 (CET)

> I deleted all occurances of #pragma interface from my 41 headers,
> and the result is:

> 		   Compile time         Size of resulting
> 		   on my PPro200        shared library
> 		   ---------------------------------------
> With #pragma       86 s                 1649639 bytes
> Without #pragma    86 s                 1663340 bytes

Thanks for the information.  It'd be nice to track down these random
few bytes that were not squeezed out, and squeeze a little more, I
think we should be able to reduce the number to be the same or better,
but we really want a small testcase, or a good explanation to fix it.

Re: #pragma interface && generating virtual tables (of templates?)

[Martin v. Loewis]

> > With #pragma       86 s                 1649639 bytes
> > Without #pragma    86 s                 1663340 bytes
> 
> Thanks for the information.  It'd be nice to track down these random
> few bytes that were not squeezed out

One source certainly is garbage exception regions. If we have linkonce
functions, they get slots in .gcc_except_table, and .eh_frame. Once
duplicate code is removed, the duplicate slots stay. I don't know
whether this would accound for the 14K; having a section-by-section
comparison would be helpful.

Regards,
Martin

Re: #pragma interface && generating virtual tables (of templates?)

[Martin v. Loewis]

> > With #pragma       86 s                 1649639 bytes
> > Without #pragma    86 s                 1663340 bytes
> 
> Thanks for the information.  It'd be nice to track down these random
> few bytes that were not squeezed out

One source certainly is garbage exception regions. If we have linkonce
functions, they get slots in .gcc_except_table, and .eh_frame. Once
duplicate code is removed, the duplicate slots stay. I don't know
whether this would accound for the 14K; having a section-by-section
comparison would be helpful.

Regards,
Martin

Re: #pragma interface && generating virtual tables (of templates?)

[Mike Stump]

> From: Carlo Wood <carlo@runaway.xs4all.nl>
> Date: Sun, 21 Feb 1999 02:46:18 +0100 (CET)

> I deleted all occurances of #pragma interface from my 41 headers,
> and the result is:

> 		   Compile time         Size of resulting
> 		   on my PPro200        shared library
> 		   ---------------------------------------
> With #pragma       86 s                 1649639 bytes
> Without #pragma    86 s                 1663340 bytes

Thanks for the information.  It'd be nice to track down these random
few bytes that were not squeezed out, and squeeze a little more, I
think we should be able to reduce the number to be the same or better,
but we really want a small testcase, or a good explanation to fix it.