-frepo bugs in 1.1.1?

-frepo bugs in 1.1.1?

[Dale E. Martin]

I have a very large project I'm working on that makes use of templates.
We're using the "Borland Model" of templates where everything for a
template class goes in the header file.  I ran "strings" on my binary the
other day, and noticed that commonly used template classes appear to be
instantiated in the binary a _lot_ of times.  I hadn't tried using -frepo
in a long time, and my reading of the docs led me to believe that all I
needed to do (since I am using the Borland model) is set the flag -frepo at 
compile time.  But, with that flag I get link errors saying some template
instantiations are missing.

Are there bugs in -frepo in egcs-1.1.1?

What kind of info could I provide that would be useful?

Thanks,
	Dale
-- 
+------------------------- pgp key available --------------------------+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer    |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com         |
+----------------------------------------------------------------------+

Re: -frepo bugs in 1.1.1?

[Alexandre Oliva]

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

On Mar  8, 1999, dmartin@clifton-labs.com (Dale E. Martin) wrote:

> other day, and noticed that commonly used template classes appear to be
> instantiated in the binary a _lot_ of times.

Why do you think so?  Which platform is that?  What linker are you using?

> Are there bugs in -frepo in egcs-1.1.1?

AFAIR, yes.

-- 
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: -frepo bugs in 1.1.1?

[Dale E. Martin]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

> Why do you think so?  

As one example - if I run "strings scram | grep "dl_list" | wc -l" on my
binary, I get 262 lines of output.  "dl_list" is a very small template
class.  So I'm assuming it's due to multiple instances.  Is this a bad
assumption?  Could it be due to inlining? Even if I'm compiling without
optimization?

Here's what the lines look like:

class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const 
class IIR_Declaration *)
util/dl_list.hh
class wrapper_container * dl_list<char>::find<char>(const char *)
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const 
class IIR_Declaration *)
util/dl_list.hh
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const 
class IIR_Declaration *)
util/dl_list.hh
bool dl_list<IIR_Declaration>::remove<IIR_Declaration>(const class IIR_Declarati
on *)
class wrapper_container * dl_list<char>::find<char>(const char *)
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const 
class IIR_Declaration *)
util/dl_list.hh
class wrapper_container * dl_list<IIR>::find<IIR>(const class IIR *)
bool dl_list<IIR>::remove<IIR>(const class IIR *)
class wrapper_container * dl_list<declaration_chain>::find<declaration_chain>(co
nst class declaration_chain *)
util/dl_list.hh
class wrapper_container * dl_list<IIR>::find<IIR>(const class IIR *)
util/dl_list.hh

LOTS of them are for <IIR_Declaration>, and there are many
dl_list<IIR_Declaration> instantiations in my code, hence my assumption.

> Which platform is that?  

Linux glibc-2.0.7 - it's Debian 2.1 box.

>What linker are you using?
 
~> ld --version
GNU ld 2.9.1

> > Are there bugs in -frepo in egcs-1.1.1?
> 
> AFAIR, yes.

Am I barking up the wrong tree?

Thanks,
	Dale
-- 
+------------------------- pgp key available --------------------------+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer    |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com         |
+----------------------------------------------------------------------+

Re: -frepo bugs in 1.1.1?

[Alexandre Oliva]

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

On Mar  8, 1999, dmartin@clifton-labs.com (Dale E. Martin) wrote:

> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
>> Why do you think so?  

> As one example - if I run "strings scram | grep "dl_list" | wc -l" on my
> binary, I get 262 lines of output.  "dl_list" is a very small template
> class.  So I'm assuming it's due to multiple instances.  Is this a bad
> assumption?  Could it be due to inlining? Even if I'm compiling without
> optimization?

What about debugging?

Try `nm --demangle' instead of `strings'; if you get more than one
definition (not `U') for each symbol, you may have found a problem.

-- 
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: -frepo bugs in 1.1.1?

[Dale E. Martin]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

> What about debugging?

Even with it stripped:
strings scram | grep "dl_list<IIR_Declaration>::find"

class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const class IIR_Declaration *)
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const class IIR_Declaration *)
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const class IIR_Declaration *)
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const class IIR_Declaration *)

[ repeat 70 more times ] 

It was on a stripped and optimized binary that I started playing around
with originally.  I was trying to figure out how my binary was so large.
(Although with egcs it's about half the size as compared with g++-2.7.2.)

> Try `nm --demangle' instead of `strings'; if you get more than one
> definition (not `U') for each symbol, you may have found a problem.

Interesting - that only shows it once in the binary.  So, here's what I
know:
1) The string listed above, makes up 7k of my binary even after stripping it.
2) If I compile with "-frepo", I get linker errors (on other template
classes.)  

I find 2) less interesting if -frepo isn't going to shrink my binary
anyways, and I guess we're pretty sure it won't due to "nm --demangle"
showing the function actually being defined only once.

So I wonder what's up with the repeated strings?  Could it be due to an
assertion in that method?  (So that the assertion can print the function
name?) As I said, the definition of the method is in the header so the
assertion would be included everywhere the class is referenced...

-- 
+------------------------- pgp key available --------------------------+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer    |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com         |
+----------------------------------------------------------------------+

Re: -frepo bugs in 1.1.1?

[Alexandre Oliva]

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

On Mar  8, 1999, dmartin@clifton-labs.com (Dale E. Martin) wrote:

> So I wonder what's up with the repeated strings?  Could it be due to an
> assertion in that method?  (So that the assertion can print the function
> name?)

Yep, it certainly could, especially because unmangled names are not
usually stored in binaries, and you report you've got them unmangled.

-- 
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: -frepo bugs in 1.1.1?

[Dale E. Martin]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

> Yep, it certainly could, especially because unmangled names are not
> usually stored in binaries, and you report you've got them unmangled.

OK - that looks like assertions are the explanation of the repeated
strings.  I still don't know why -frepo doesn't work with this code, but
I'm not too concerned about that at this point.

Thanks for the help!

Later,
	Dale
-- 
+------------------------- pgp key available --------------------------+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer    |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com         |
+----------------------------------------------------------------------+

Re: -frepo bugs in 1.1.1?

[Joe Buck]

[ issue with seemingly redundant code from template expansions ]

> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
> 
> > Yep, it certainly could, especially because unmangled names are not
> > usually stored in binaries, and you report you've got them unmangled.

Dale Martin writes:

> OK - that looks like assertions are the explanation of the repeated
> strings.  I still don't know why -frepo doesn't work with this code, but
> I'm not too concerned about that at this point.

I recall that there is a longstanding gcc bug that once a string literal
is generated, it winds up in the code regardless of whether it is used.
It's been low priority because all it does is make your executable bigger,
but that is what is probably happening here.

One question is whether the strings are the only redundant code you are
getting, or if there is other waste as wll.

Re: -frepo bugs in 1.1.1?

[Joe Buck]

[ issue with seemingly redundant code from template expansions ]

> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
> 
> > Yep, it certainly could, especially because unmangled names are not
> > usually stored in binaries, and you report you've got them unmangled.

Dale Martin writes:

> OK - that looks like assertions are the explanation of the repeated
> strings.  I still don't know why -frepo doesn't work with this code, but
> I'm not too concerned about that at this point.

I recall that there is a longstanding gcc bug that once a string literal
is generated, it winds up in the code regardless of whether it is used.
It's been low priority because all it does is make your executable bigger,
but that is what is probably happening here.

One question is whether the strings are the only redundant code you are
getting, or if there is other waste as wll.

Re: -frepo bugs in 1.1.1?

[Dale E. Martin]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

> Yep, it certainly could, especially because unmangled names are not
> usually stored in binaries, and you report you've got them unmangled.

OK - that looks like assertions are the explanation of the repeated
strings.  I still don't know why -frepo doesn't work with this code, but
I'm not too concerned about that at this point.

Thanks for the help!

Later,
	Dale
-- 
+------------------------- pgp key available --------------------------+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer    |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com         |
+----------------------------------------------------------------------+

Re: -frepo bugs in 1.1.1?

[Alexandre Oliva]

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

On Mar  8, 1999, dmartin@clifton-labs.com (Dale E. Martin) wrote:

> So I wonder what's up with the repeated strings?  Could it be due to an
> assertion in that method?  (So that the assertion can print the function
> name?)

Yep, it certainly could, especially because unmangled names are not
usually stored in binaries, and you report you've got them unmangled.

-- 
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: -frepo bugs in 1.1.1?

[Dale E. Martin]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

> What about debugging?

Even with it stripped:
strings scram | grep "dl_list<IIR_Declaration>::find"

class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const class IIR_Declaration *)
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const class IIR_Declaration *)
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const class IIR_Declaration *)
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const class IIR_Declaration *)

[ repeat 70 more times ] 

It was on a stripped and optimized binary that I started playing around
with originally.  I was trying to figure out how my binary was so large.
(Although with egcs it's about half the size as compared with g++-2.7.2.)

> Try `nm --demangle' instead of `strings'; if you get more than one
> definition (not `U') for each symbol, you may have found a problem.

Interesting - that only shows it once in the binary.  So, here's what I
know:
1) The string listed above, makes up 7k of my binary even after stripping it.
2) If I compile with "-frepo", I get linker errors (on other template
classes.)  

I find 2) less interesting if -frepo isn't going to shrink my binary
anyways, and I guess we're pretty sure it won't due to "nm --demangle"
showing the function actually being defined only once.

So I wonder what's up with the repeated strings?  Could it be due to an
assertion in that method?  (So that the assertion can print the function
name?) As I said, the definition of the method is in the header so the
assertion would be included everywhere the class is referenced...

-- 
+------------------------- pgp key available --------------------------+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer    |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com         |
+----------------------------------------------------------------------+

Re: -frepo bugs in 1.1.1?

[Alexandre Oliva]

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

On Mar  8, 1999, dmartin@clifton-labs.com (Dale E. Martin) wrote:

> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
>> Why do you think so?  

> As one example - if I run "strings scram | grep "dl_list" | wc -l" on my
> binary, I get 262 lines of output.  "dl_list" is a very small template
> class.  So I'm assuming it's due to multiple instances.  Is this a bad
> assumption?  Could it be due to inlining? Even if I'm compiling without
> optimization?

What about debugging?

Try `nm --demangle' instead of `strings'; if you get more than one
definition (not `U') for each symbol, you may have found a problem.

-- 
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: -frepo bugs in 1.1.1?

[Dale E. Martin]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

> Why do you think so?  

As one example - if I run "strings scram | grep "dl_list" | wc -l" on my
binary, I get 262 lines of output.  "dl_list" is a very small template
class.  So I'm assuming it's due to multiple instances.  Is this a bad
assumption?  Could it be due to inlining? Even if I'm compiling without
optimization?

Here's what the lines look like:

class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const 
class IIR_Declaration *)
util/dl_list.hh
class wrapper_container * dl_list<char>::find<char>(const char *)
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const 
class IIR_Declaration *)
util/dl_list.hh
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const 
class IIR_Declaration *)
util/dl_list.hh
bool dl_list<IIR_Declaration>::remove<IIR_Declaration>(const class IIR_Declarati
on *)
class wrapper_container * dl_list<char>::find<char>(const char *)
class wrapper_container * dl_list<IIR_Declaration>::find<IIR_Declaration>(const 
class IIR_Declaration *)
util/dl_list.hh
class wrapper_container * dl_list<IIR>::find<IIR>(const class IIR *)
bool dl_list<IIR>::remove<IIR>(const class IIR *)
class wrapper_container * dl_list<declaration_chain>::find<declaration_chain>(co
nst class declaration_chain *)
util/dl_list.hh
class wrapper_container * dl_list<IIR>::find<IIR>(const class IIR *)
util/dl_list.hh

LOTS of them are for <IIR_Declaration>, and there are many
dl_list<IIR_Declaration> instantiations in my code, hence my assumption.

> Which platform is that?  

Linux glibc-2.0.7 - it's Debian 2.1 box.

>What linker are you using?
 
~> ld --version
GNU ld 2.9.1

> > Are there bugs in -frepo in egcs-1.1.1?
> 
> AFAIR, yes.

Am I barking up the wrong tree?

Thanks,
	Dale
-- 
+------------------------- pgp key available --------------------------+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer    |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com         |
+----------------------------------------------------------------------+

Re: -frepo bugs in 1.1.1?

[Alexandre Oliva]

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

On Mar  8, 1999, dmartin@clifton-labs.com (Dale E. Martin) wrote:

> other day, and noticed that commonly used template classes appear to be
> instantiated in the binary a _lot_ of times.

Why do you think so?  Which platform is that?  What linker are you using?

> Are there bugs in -frepo in egcs-1.1.1?

AFAIR, yes.

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

-frepo bugs in 1.1.1?

[Dale E. Martin]

I have a very large project I'm working on that makes use of templates.
We're using the "Borland Model" of templates where everything for a
template class goes in the header file.  I ran "strings" on my binary the
other day, and noticed that commonly used template classes appear to be
instantiated in the binary a _lot_ of times.  I hadn't tried using -frepo
in a long time, and my reading of the docs led me to believe that all I
needed to do (since I am using the Borland model) is set the flag -frepo at 
compile time.  But, with that flag I get link errors saying some template
instantiations are missing.

Are there bugs in -frepo in egcs-1.1.1?

What kind of info could I provide that would be useful?

Thanks,
	Dale
-- 
+------------------------- pgp key available --------------------------+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer    |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com         |
+----------------------------------------------------------------------+

Re: -frepo bugs in 1.1.1?

[Jason Merrill]

>>>>> Dale E Martin <dmartin@clifton-labs.com> writes:

 > Are there bugs in -frepo in egcs-1.1.1?

Some were fixed, but there may be others.

 > What kind of info could I provide that would be useful?

A testcase so we can reproduce the problem.

Jason

Re: -frepo bugs in 1.1.1?

[Dale E. Martin]

Jason Merrill <jason@cygnus.com> writes:

> A testcase so we can reproduce the problem.

I'd love to be able to provide a small testcase.  The system I'm working
with is large though.  The small cases I've played with work fine.

I guess my main problem is that I'm well versed in solving linker problems
using "nm" and experience, but I don't have any idea about how to debug
".rpo" files and all of that. Is there documentation available describing
what's going on besides the egcs info file?

Thanks,
	Dale
-- 
+------------------------- pgp key available --------------------------+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer    |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com         |
+----------------------------------------------------------------------+

Re: -frepo bugs in 1.1.1?

[Dale E. Martin]

Jason Merrill <jason@cygnus.com> writes:

> A testcase so we can reproduce the problem.

I'd love to be able to provide a small testcase.  The system I'm working
with is large though.  The small cases I've played with work fine.

I guess my main problem is that I'm well versed in solving linker problems
using "nm" and experience, but I don't have any idea about how to debug
".rpo" files and all of that. Is there documentation available describing
what's going on besides the egcs info file?

Thanks,
	Dale
-- 
+------------------------- pgp key available --------------------------+
| Dale E. Martin |  Clifton Labs, Inc.  |  Senior Computer Engineer    |
| dmartin@clifton-labs.com    |    http://www.clifton-labs.com         |
+----------------------------------------------------------------------+

Re: -frepo bugs in 1.1.1?

[Jason Merrill]

>>>>> Dale E Martin <dmartin@clifton-labs.com> writes:

 > Are there bugs in -frepo in egcs-1.1.1?

Some were fixed, but there may be others.

 > What kind of info could I provide that would be useful?

A testcase so we can reproduce the problem.

Jason

Re: -frepo bugs in 1.1.1?

[Mike Stump]

> From: dmartin@clifton-labs.com (Dale E. Martin)
> Date: 	08 Mar 1999 15:32:06 -0500

> Jason Merrill <jason@cygnus.com> writes:

> > A testcase so we can reproduce the problem.

> I'd love to be able to provide a small testcase.  The system I'm working
> with is large though.  The small cases I've played with work fine.

> I guess my main problem is that I'm well versed in solving linker
> problems using "nm" and experience, but I don't have any idea about
> how to debug ".rpo" files and all of that. Is there documentation
> available describing what's going on besides the egcs info file?

I can try and help you submit a bug report...  

First identify what symbol isn't being generated.  Be sure to figure
out the undemangled version.  confirm with nm.

Then, find out what file uses it (nm | grep 'U sym' will confirm a
use), and that it could be instantiated in.  Review output from -E on
the compile and ensure that the thing you want a definition for is
_defined_.  If not _defined_, fix source code or go back to this step.

grep around in the rpo file for the symbol, and file this information
along with the souce code to this _one_ file along with the linker
error message about not finding it.  Include the undemangled version
of the error message, please, not the demangled version.  Ensure that
the spelling is byte for byte identical.

This is mostly the same process of non-template code.  If you can
reduce the size of the file, without affecting the fundamentals of it,
that helps, and realistically will increase the odds of the bug being
fixed, but it isn't necessary for submission of a bug report.  Only
compression is required if it is large.

Hope this helps.

Re: -frepo bugs in 1.1.1?

[Mike Stump]

> From: dmartin@clifton-labs.com (Dale E. Martin)
> Date: 	08 Mar 1999 15:32:06 -0500

> Jason Merrill <jason@cygnus.com> writes:

> > A testcase so we can reproduce the problem.

> I'd love to be able to provide a small testcase.  The system I'm working
> with is large though.  The small cases I've played with work fine.

> I guess my main problem is that I'm well versed in solving linker
> problems using "nm" and experience, but I don't have any idea about
> how to debug ".rpo" files and all of that. Is there documentation
> available describing what's going on besides the egcs info file?

I can try and help you submit a bug report...  

First identify what symbol isn't being generated.  Be sure to figure
out the undemangled version.  confirm with nm.

Then, find out what file uses it (nm | grep 'U sym' will confirm a
use), and that it could be instantiated in.  Review output from -E on
the compile and ensure that the thing you want a definition for is
_defined_.  If not _defined_, fix source code or go back to this step.

grep around in the rpo file for the symbol, and file this information
along with the souce code to this _one_ file along with the linker
error message about not finding it.  Include the undemangled version
of the error message, please, not the demangled version.  Ensure that
the spelling is byte for byte identical.

This is mostly the same process of non-template code.  If you can
reduce the size of the file, without affecting the fundamentals of it,
that helps, and realistically will increase the odds of the bug being
fixed, but it isn't necessary for submission of a bug report.  Only
compression is required if it is large.

Hope this helps.