Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

Hi,

I have no idea if this patch is correct. But it works for me. gcc
seems to pick a poor choice of function name for global constructors
and destructors. It may not be unique across files.

Thanks.

H.J.
----
Fri Jan 29 17:15:59 1999  H.J. Lu  (hjl@gnu.org)

	* decl2.c (start_objects): Make global constructors and
	destructors unique.


--- ../../../../import/egcs-1.1.1/egcs/gcc/cp/decl2.c	Mon Nov  9 01:32:04 1998
+++ ./decl2.c	Fri Jan 29 17:18:18 1999
@@ -2943,6 +2943,12 @@ start_objects (method_type)
 					NULL_TREE),
 		  NULL_TREE, 0);
 
+  /* It is a file scope function. */
+  if (flag_weak)
+    make_decl_one_only (current_function_decl);
+  else
+    TREE_PUBLIC (current_function_decl) = 0;
+
   store_parm_decls ();
   pushlevel (0);
   clear_last_expr ();



--
Forwarded message:

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Alexandre Oliva]

On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:

> I have no idea if this patch is correct. But it works for me. gcc
> seems to pick a poor choice of function name for global constructors
> and destructors. It may not be unique across files.

AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
matter of porting his fix to the branch.

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

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:
> 
> > I have no idea if this patch is correct. But it works for me. gcc
> > seems to pick a poor choice of function name for global constructors
> > and destructors. It may not be unique across files.
> 
> AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
> matter of porting his fix to the branch.
> 

I saw the fix. It should be back ported to 1.1.2. However, Jason' fix
is not 100% safe since it bets on luck. My second patch is 100% safe.
But it only covers ctors/dtors in C++ and only works on ELF.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m106iAc-000390C@ocean.lucon.org >you write:
  > > 
  > > On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:
  > > 
  > > > I have no idea if this patch is correct. But it works for me. gcc
  > > > seems to pick a poor choice of function name for global constructors
  > > > and destructors. It may not be unique across files.
  > > 
  > > AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
  > > matter of porting his fix to the branch.
  > > 
  > 
  > I saw the fix. It should be back ported to 1.1.2. However, Jason' fix
  > is not 100% safe since it bets on luck. My second patch is 100% safe.
  > But it only covers ctors/dtors in C++ and only works on ELF.
In what way does it "bets on luck"?

Such statements carry far more weight when you take the time to explain them.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
>   In message < m106iAc-000390C@ocean.lucon.org >you write:
>   > > 
>   > > On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:
>   > > 
>   > > > I have no idea if this patch is correct. But it works for me. gcc
>   > > > seems to pick a poor choice of function name for global constructors
>   > > > and destructors. It may not be unique across files.
>   > > 
>   > > AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
>   > > matter of porting his fix to the branch.
>   > > 
>   > 
>   > I saw the fix. It should be back ported to 1.1.2. However, Jason' fix
>   > is not 100% safe since it bets on luck. My second patch is 100% safe.
>   > But it only covers ctors/dtors in C++ and only works on ELF.
> In what way does it "bets on luck"?
> 
> Such statements carry far more weight when you take the time to explain them.
> 

I will try to explain it here. This is from tree.c:

/* Generate a name for a function unique to this translation unit.
   TYPE is some string to identify the purpose of this function to the
   linker or collect2.  */
       
tree
get_file_function_name_long (type)
     char *type;
{
  ...
}

It is ok if the function is really local to the translation unit.
Let's assume the condition is true. Then there is no need to call
append_random_chars (). We can use a static counter for that
purpose.

Unfortunately, the comments for get_file_function_name_long () are
misleading. Under certain conditions, it is called to generate a name
for a global function unique to the resulting executable binary and all
the shared libraries it uses. One such a case is start_objects () in
cp/decl2.c. It calls get_file_function_name_long to generate a
global function which is used for the C++ file scope constructors
and destructors. My guess for making it global is on some platforms
collect2 is needed to pull out those functions to make sure they
are called at the right time and order. Since it is global, it has
to be unique the executable and all the shared libraries it uses.
Otherwise, you will get a linker error. Even worse a wrong function
may be called. I think it may happen with shared libraries. Linker
may override the function in shared libraries with the one in the
executable if they have the same name. This may lead to disaster
for everyone.

My questions are

1. Can we identify the cases where get_file_function_name_long () is
called to generate a name for a global function unique to the
resulting executable binary and all the shared libraries it uses?
2. Do they have to be global?

In case of the C++ ctor/dtor, collect2 is not needed for ELF, we can
make it local. My patch does that. If they have to be global, we can
add strftime () with hostname in addition to append_random_chars ().
It should have better chances to be unique. But I really want to get
rid of the global function all together.


H.J.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> 1. Can we identify the cases where get_file_function_name_long () is
> called to generate a name for a global function unique to the
> resulting executable binary and all the shared libraries it uses?

There are currently three different 'type' arguments passed to that
function, 'D', 'I', and 'N'. For 'D' and 'I', additional mangling
might indicate the initializer priority. For 'N', the resulting name
will be an anonymous namespace.

> 2. Do they have to be global?

In the case of anonymous namespaces, absolutely, yes. I proposed to
make anonymous namespaces (and everything inside) static at one time,
but it was decided that this approach would defeat upcoming
implementations of exported templates.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > 1. Can we identify the cases where get_file_function_name_long () is
> > called to generate a name for a global function unique to the
> > resulting executable binary and all the shared libraries it uses?
> 
> There are currently three different 'type' arguments passed to that
> function, 'D', 'I', and 'N'. For 'D' and 'I', additional mangling
> might indicate the initializer priority. For 'N', the resulting name
> will be an anonymous namespace.

Do 'D' and 'I' have to be global?

> 
> > 2. Do they have to be global?
> 
> In the case of anonymous namespaces, absolutely, yes. I proposed to
> make anonymous namespaces (and everything inside) static at one time,
> but it was decided that this approach would defeat upcoming
> implementations of exported templates.
> 

I am not sure if we should worry about anonymous namespaces. What
will happen when 2 anonymous namespaces have the same name?


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> Do 'D' and 'I' have to be global?

I'm not sure. As you've found, they don't have to be for ELF. I don't
know what the rationale was for making them global; it seems this
knowledge is lost...

> I am not sure if we should worry about anonymous namespaces. What
> will happen when 2 anonymous namespaces have the same name?

Bad things. Anonymous namespaces allow you to put

namespace{
  int dummy;
}

into a header file, and you should get a different variable in each
object file. More importantly, you can do

namespace{
  class Handle{
    Handle(){}
  };
}

in an implementation and expect that it won't clash with somebody
else's Handle class. If the two anonymous namespaces have the same
name, you'll get a clash.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > Do 'D' and 'I' have to be global?
> 
> I'm not sure. As you've found, they don't have to be for ELF. I don't
> know what the rationale was for making them global; it seems this
> knowledge is lost...
> 

collect2 is used for globcl ctors/dtors on some systems.

> > I am not sure if we should worry about anonymous namespaces. What
> > will happen when 2 anonymous namespaces have the same name?
> 
> Bad things. Anonymous namespaces allow you to put
> 
> namespace{
>   int dummy;
> }
> 
> into a header file, and you should get a different variable in each
> object file. More importantly, you can do
> 
> namespace{
>   class Handle{
>     Handle(){}
>   };
> }
> 
> in an implementation and expect that it won't clash with somebody
> else's Handle class. If the two anonymous namespaces have the same
> name, you'll get a clash.

How about we use

	machinename+pid+filename+strftime+staticcounter+randomstuff

The possiblility for clash should be very low. I'd like to see it
be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> How about we use
> 
> 	machinename+pid+filename+strftime+staticcounter+randomstuff
> 
> The possiblility for clash should be very low. I'd like to see it
> be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.

I just had a complaint of somebody running into the same problem,
different scenario:

He had a number of shared libraries, all starting with the same global
function. Of course, this is ill-formed (duplicate definitions), but
the linker didn't complain, so he thought it's all-right. But it
wasn't: g++ keyed initializers to this function, and the same
initializer got invoked twice; another initializer wasn't called.

So I now think that the initializer symbols should be static if we are
not collect2ing them. 

Still, coming up with a better 'unique hash' is worthwhile. It should
be well-designed though: We had several attempts to do it right, and
still didn't. In your proposal, I see a number of problems:

a) pid, randomstuff might not be available on all systems. In
   particular, systems that don't get initializers right probably
   don't have a number of other things.

b) Don't produce too long strings. It might exceed assembler
   restrictions.

Regards,
Martin
 

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > How about we use
> > 
> > 	machinename+pid+filename+strftime+staticcounter+randomstuff
> > 
> > The possiblility for clash should be very low. I'd like to see it
> > be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.
> 
> I just had a complaint of somebody running into the same problem,
> different scenario:
> 
> He had a number of shared libraries, all starting with the same global
> function. Of course, this is ill-formed (duplicate definitions), but
> the linker didn't complain, so he thought it's all-right. But it
> wasn't: g++ keyed initializers to this function, and the same
> initializer got invoked twice; another initializer wasn't called.
> 
> So I now think that the initializer symbols should be static if we are
> not collect2ing them. 

That is what I have been saying all along.

> 
> Still, coming up with a better 'unique hash' is worthwhile. It should
> be well-designed though: We had several attempts to do it right, and
> still didn't. In your proposal, I see a number of problems:
> 
> a) pid, randomstuff might not be available on all systems. In
>    particular, systems that don't get initializers right probably
>    don't have a number of other things.
> 
> b) Don't produce too long strings. It might exceed assembler
>    restrictions.
> 

My proposal does have some limitations. I hope someone can come
up with a better solution. This serious bug must be fixed in
egcs 1.1.2. The sooner, the better.

Please remember we need a universal unique hash for every different
file on every single machine for the same platform. It is a tough
one. But we have to do it.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m108PtF-00038sC@ocean.lucon.org >you write:
  > My proposal does have some limitations. I hope someone can come
  > up with a better solution. This serious bug must be fixed in
  > egcs 1.1.2. The sooner, the better.
So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
concrete yet.


jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
> concrete yet.

I think the minimal solution is to make initializer symbols static on
ELF systems. HJ has a patch, although I haven't reviewed it to see
whether it does what it promises to do.

If somebody can propose a patch that produces significantly
more-unique symbols than the current code, this should also go into 1.2.
In this respect, HJ's other patch does not qualify, IMHO.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
> > concrete yet.
> 
> I think the minimal solution is to make initializer symbols static on
> ELF systems. HJ has a patch, although I haven't reviewed it to see
> whether it does what it promises to do.

I am only interested in Linux. If we really cannot fix the problem for
all platforms, it is ok with me as long as Linux is ok :-(.

> 
> If somebody can propose a patch that produces significantly
> more-unique symbols than the current code, this should also go into 1.2.
> In this respect, HJ's other patch does not qualify, IMHO.
> 

To me, "significantly more-unique" is still bet on luck. I really
don't like it. I will do something for Linux one way or the other
if I don't like what I see.


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10BoHn-000392C@ocean.lucon.org >you write:
  > > 
  > > > So what is the consensus solution for egcs-1.1.2?  I haven't seen anyth
  > ing
  > > > concrete yet.
  > > 
  > > I think the minimal solution is to make initializer symbols static on
  > > ELF systems. HJ has a patch, although I haven't reviewed it to see
  > > whether it does what it promises to do.
  > 
  > I am only interested in Linux. If we really cannot fix the problem for
  > all platforms, it is ok with me as long as Linux is ok :-(.
That may be your only concern, but this project is not just a linux compiler.
We have to think about broader scopes than just linux.



jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
>   In message < m10BoHn-000392C@ocean.lucon.org >you write:
>   > > 
>   > > > So what is the consensus solution for egcs-1.1.2?  I haven't seen anyth
>   > ing
>   > > > concrete yet.
>   > > 
>   > > I think the minimal solution is to make initializer symbols static on
>   > > ELF systems. HJ has a patch, although I haven't reviewed it to see
>   > > whether it does what it promises to do.
>   > 
>   > I am only interested in Linux. If we really cannot fix the problem for
>   > all platforms, it is ok with me as long as Linux is ok :-(.
> That may be your only concern, but this project is not just a linux compiler.
> We have to think about broader scopes than just linux.
> 

It is a very hard problem. It may not have solutons for all platforms.
But it doesn't mean we should not fix those we can fix.


H.J.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10Boh4-000392C@ocean.lucon.org >you write:
  > It is a very hard problem. It may not have solutons for all platforms.
  > But it doesn't mean we should not fix those we can fix.
But it also doesn't mean we take the stance of fixing linux and ignoring
everything else.

Furthermore, this is an ABI/API change, we want to be very careful making
such changes.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
> 
>   In message < m10Boh4-000392C@ocean.lucon.org >you write:
>   > It is a very hard problem. It may not have solutons for all platforms.
>   > But it doesn't mean we should not fix those we can fix.
> But it also doesn't mean we take the stance of fixing linux and ignoring
> everything else.
> 

Here is my proposal. main () in toplev.c calls unique_string () to
initialize a static variable in tree.c:

static char *file_function_name_base;

with

	file_function_name_base = unique_string ();

We also add a counter in tree.c:

static int file_function_name_counter;

get_file_function_name in tree.c will create a file funtcion name with

	file_function_name = file_function_name_base
			     + main_input_filename
			     + file_function_name_counter;

This way we can say with quite confidence that file_function_name will
be unique across all machines in the world for a given OS on a given
arch if they are configured properly. Of course, it may not work for
all OSes. But it should cover most if not all Unix-alike systems.

> Furthermore, this is an ABI/API change, we want to be very careful making
> such changes.
> 

I am not sure if the ABI/API change caused by making global ctors/dtors
static is visible to user. At least, it should be safe on ELF systems.


-- 
H.J. Lu (hjl@gnu.org)
---
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#if defined HAVE_SYS_UTSNAME_H && defined HAVE_UNAME
#include <sys/utsname.h>
#endif

#if defined HAVE_TIME_H && defined HAVE_STRFTIME \
    && defined HAVE_GMTIME && defined HAVE_TIME
#include <time.h>
#endif

#define xmalloc	malloc

#define is_valid_symbol_char(c) \
  ((c) == '_' || (c) == '.' || ((c) >= '0' && (c) <= '9') \
   || ((c) >= 'a' && (c) <= 'z') || ((c) >= 'A' && (c) <= 'Z'))

char *
unique_string ()
{
  char *domainname = NULL;
  char *hostname = NULL;
  char *sysname = NULL;
  char *release = NULL;
  char *version = NULL;
  char *machine = NULL;
  char current_time [] = "yyyymmddhhmmss";
  long pid = getpid ();
  char *unique_name;
  int len;

#ifdef HAVE_GETDOMAINNAME
  {
    len = 0;
    do
      {
	len += 128;
	domainname = (char *) alloca (len);
	if (getdomainname (domainname, len) == 0)
	  break;
	else
	  domainname = NULL;
      }
    while (len < 512);
  }
#endif

#ifdef HAVE_GETHOSTNAME
  {
    len = 0;
    do
      {
	len += 128;
	hostname = (char *) alloca (len);
	if (gethostname (hostname, len) == 0)
	  break;
	else
	  hostname = NULL;
      }
    while (len < 512);
  }
#endif

#if defined HAVE_UNAME && defined HAVE_SYS_UTSNAME_H
  {
    struct utsname utsname;

    if (uname (&utsname) == 0)
      {
#ifdef HAVE_DOMAINNAME_IN_UTSNAME
        if (!domainname)
	  domainname = utsname.domainname;
#endif
#ifdef HAVE_NODENAME_IN_UTSNAME
        if (!hostname)
	  hostname = utsname.nodename;
#endif
#ifdef HAVE_SYSNAME_IN_UTSNAME
	sysname = utsname.sysname;
#endif
#ifdef HAVE_RELEASE_IN_UTSNAME
	release = utsname.release;
#endif
#ifdef HAVE_VERSION_IN_UTSNAME
	version = utsname.version;
#endif
#ifdef HAVE_MACHINE_IN_UTSNAME
	machine = utsname.machine;
#endif
      }
  }
#endif

  if (!domainname || *domainname == '\0')
    domainname = "localdomain";

  if (!hostname || *hostname == '\0')
    hostname = "localhost";

  if (!sysname || *sysname == '\0')
    sysname = "UnknownOS";

  if (!release || *release == '\0')
    release = "UnknownRelease";

  if (!version || *version == '\0')
    version = "UnknownVersion";

  if (!machine || *machine == '\0')
    machine = "UnknownMachine";

#if defined HAVE_STRFTIME && defined HAVE_GMTIME && defined HAVE_TIME
  {
    time_t t;
    
    t = time (NULL);
    if (strftime (current_time, sizeof (current_time),
    		  "%Y%m%d%H%M%S", gmtime (&t)) == 0)
      strcpy (current_time, "yyyymmddhhmmss");
  }
#endif

  {
    char *dot = strchr (hostname, '.');

    if (!dot || strchr (++dot, '.') == NULL)
      {
        /* There are no 2 dots in hostname. We need to append the
	   domainname. */
	len = 1 + strlen (hostname) + 1 + strlen (domainname)
	      + strlen (sysname) + strlen (release) + strlen (version)
	      + strlen (machine) + sizeof (current_time) + 8;

	unique_name = xmalloc (len);

        sprintf (unique_name, "_%s.%s%s%s%s%s%s%.8x",
		 hostname, domainname, sysname, release, version,
		 machine, current_time, pid);
      }
    else
      {
	len = 1 + strlen (hostname)
	      + strlen (sysname) + strlen (release) + strlen (version)
	      + strlen (machine) + sizeof (current_time) + 8;

	unique_name = xmalloc (len);

        sprintf (unique_name, "_%s%s%s%s%s%s%.8x",
		 hostname, sysname, release, version,
		 machine, current_time, pid);
      }
  }

  {
    int i;

    for (i = 1; i < len - 1 - sizeof (current_time) - 8; i++)
      {
        if (!is_valid_symbol_char (unique_name [i]))
	  unique_name [i] = '_';
      }
  }
  return unique_name;
}

main ()
{
  printf ("%s\n", unique_string ());
}

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    H> Here is my proposal. main () in toplev.c calls unique_string ()
    H> to initialize a static variable in tree.c:

In my opinion, this is not a good proposal.  In another life, I work
on issues of computer security, and silently putting things that might
reveal the hostname where the program is compiled in .o files is not
at all a good thing.

If we can make the functions static, the problem goes away, right?  If
not, then sufficiently many random bits is just fine.  I would guess
that 2048 would be more than enough for quite some time to come.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> "H" == H J Lu <hjl@lucon.org> writes:
> 
>     H> Here is my proposal. main () in toplev.c calls unique_string ()
>     H> to initialize a static variable in tree.c:
> 
> In my opinion, this is not a good proposal.  In another life, I work
> on issues of computer security, and silently putting things that might
> reveal the hostname where the program is compiled in .o files is not
> at all a good thing.

I see. How about removing hostname and domainname?

> 
> If we can make the functions static, the problem goes away, right?  If
> not, then sufficiently many random bits is just fine.  I would guess
> that 2048 would be more than enough for quite some time to come.
> 

For anonymouse namspace, they are global. I don't think random bits
alone are any better than timestamp. How about timestamp + random bits?


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    H> I see. How about removing hostname and domainname?

Better.

    >>  If we can make the functions static, the problem goes away,
    >> right?  If not, then sufficiently many random bits is just
    >> fine.  I would guess that 2048 would be more than enough for
    >> quite some time to come.
    >> 

    H> For anonymouse namspace, they are global. I don't think random
    H> bits alone are any better than timestamp. How about timestamp +
    H> random bits?

Sure, that's fine.  But, why bother?  Random bits are very, very good.
Anything is else is an unnecessary complication.  Using more random
bits is easier that throwing in any other attempted uniquifications.

We just need a pile of bits.  If I were you, I'd seed the random
number generator with a hash of timestamp + pid + ip address, and call
it good enough.  These are all 32-bit values, on many machines, so you
can just XOR them.  On other hosts, concatenate.  It doesn't really
matter much.  Of course, this doesn't guarantee uniqueness; multiple
machines can have the same IP address.  (Especially, 192.168.x.x).
But, it should be good enough.  You could use autoconf to see if
there's a /dev/random and use that instead of the pseudo-random number
generator, if available.  Then, you don't even have to seed.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Kamil Iskra]

On Mon, 15 Feb 1999, Mark Mitchell wrote:

> We just need a pile of bits.
[snip]
> You could use autoconf to see if
> there's a /dev/random and use that instead of the pseudo-random number
> generator, if available.  Then, you don't even have to seed.

Erm, don't you perhaps mean /dev/urandom? With /dev/random, compiler could
easily use all the random numbers in kernel buffer and than would have to
wait until new ones are generated. That would be fun: one would have to
press some keys on the keyboard or ping the machine in order for the
compiler to do its job :-).

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Zack Weinberg]

On Wed, 17 Feb 1999 22:19:25 +0100 (EET), Kamil Iskra wrote:
>On Mon, 15 Feb 1999, Mark Mitchell wrote:
>
>> We just need a pile of bits.
>[snip]
>> You could use autoconf to see if
>> there's a /dev/random and use that instead of the pseudo-random number
>> generator, if available.  Then, you don't even have to seed.
>
>Erm, don't you perhaps mean /dev/urandom?

I think all this stuff is overkill.  For ELF (and XCOFF, ROSE, etc), we
localize the symbols, problem solved.  For a.out and other limited
formats, take a hash of the absolute path and the hostname, that will
be unique enough - if you're worried about exposing info, make it
cryptographically strong.

zw

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Zack Weinberg]

On Wed, 17 Feb 1999 22:19:25 +0100 (EET), Kamil Iskra wrote:
>On Mon, 15 Feb 1999, Mark Mitchell wrote:
>
>> We just need a pile of bits.
>[snip]
>> You could use autoconf to see if
>> there's a /dev/random and use that instead of the pseudo-random number
>> generator, if available.  Then, you don't even have to seed.
>
>Erm, don't you perhaps mean /dev/urandom?

I think all this stuff is overkill.  For ELF (and XCOFF, ROSE, etc), we
localize the symbols, problem solved.  For a.out and other limited
formats, take a hash of the absolute path and the hostname, that will
be unique enough - if you're worried about exposing info, make it
cryptographically strong.

zw

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Kamil Iskra]

On Mon, 15 Feb 1999, Mark Mitchell wrote:

> We just need a pile of bits.
[snip]
> You could use autoconf to see if
> there's a /dev/random and use that instead of the pseudo-random number
> generator, if available.  Then, you don't even have to seed.

Erm, don't you perhaps mean /dev/urandom? With /dev/random, compiler could
easily use all the random numbers in kernel buffer and than would have to
wait until new ones are generated. That would be fun: one would have to
press some keys on the keyboard or ping the machine in order for the
compiler to do its job :-).

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    H> I see. How about removing hostname and domainname?

Better.

    >>  If we can make the functions static, the problem goes away,
    >> right?  If not, then sufficiently many random bits is just
    >> fine.  I would guess that 2048 would be more than enough for
    >> quite some time to come.
    >> 

    H> For anonymouse namspace, they are global. I don't think random
    H> bits alone are any better than timestamp. How about timestamp +
    H> random bits?

Sure, that's fine.  But, why bother?  Random bits are very, very good.
Anything is else is an unnecessary complication.  Using more random
bits is easier that throwing in any other attempted uniquifications.

We just need a pile of bits.  If I were you, I'd seed the random
number generator with a hash of timestamp + pid + ip address, and call
it good enough.  These are all 32-bit values, on many machines, so you
can just XOR them.  On other hosts, concatenate.  It doesn't really
matter much.  Of course, this doesn't guarantee uniqueness; multiple
machines can have the same IP address.  (Especially, 192.168.x.x).
But, it should be good enough.  You could use autoconf to see if
there's a /dev/random and use that instead of the pseudo-random number
generator, if available.  Then, you don't even have to seed.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> Mark Mitchell <mark@markmitchell.com> writes:

>>>>> "H" == H J Lu <hjl@lucon.org> writes:
 H> I see. How about removing hostname and domainname?

 H> For anonymouse namspace, they are global. I don't think random
 H> bits alone are any better than timestamp. How about timestamp +
 H> random bits?

 > Sure, that's fine.  But, why bother?  Random bits are very, very good.
 > Anything is else is an unnecessary complication.  Using more random
 > bits is easier that throwing in any other attempted uniquifications.

 > We just need a pile of bits.  If I were you, I'd seed the random
 > number generator with a hash of timestamp + pid + ip address, and call
 > it good enough.

The current code uses timestamp ^ pid directly, without going through the
random number generator.  The code was lifted from mkstemp in libiberty.

Really, this seems entirely adequate to me.  The number of translation
units that actually rely on this is small; witness how long it took to fix
this problem in the first place.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Mark Mitchell]

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


    Jason> The current code uses timestamp ^ pid directly, without
    Jason> going through the random number generator.  The code was
    Jason> lifted from mkstemp in libiberty.

    Jason> Really, this seems entirely adequate to me.  The number of
    Jason> translation units that actually rely on this is small;
    Jason> witness how long it took to fix this problem in the first
    Jason> place.

Probably the current approach *is* good enough.  I was operating under
the assumption that it wasn't, since HJ was concerned about it.  So, I
stand by my assertion that the right way to fix it, if it needs
fixing, is to add some random bits.  Of course, if ain't even broke,
then just leaving it be is fine, too!

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Mark Mitchell <mark@markmitchell.com>:

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

Jason> The current code uses timestamp ^ pid directly, without going
Jason> through the random number generator.  The code was lifted from
Jason> mkstemp in libiberty.

Jason> Really, this seems entirely adequate to me.  The number of
Jason> translation units that actually rely on this is small; witness
Jason> how long it took to fix this problem in the first place.

> Probably the current approach *is* good enough.  I was operating
> under the assumption that it wasn't, since HJ was concerned about
> it.

If this is the approach 1.1.1 uses on the thing that started this
thread (I'm not sure of I'm following the current discussion), this
test case will break it on linux:
	http://egcs.cygnus.com/ml/egcs-bugs/1999-02/msg00469.html

If the approach Jason lists above is the cause, the approach does not
seem adequate to me.  

What I'm doing in the real cause (not the test case) is putting self
registering singletons in .so files, and having them register
temselves with a central registry when the .so files are loaded (the
constructor of the singleton does the registration, and we create a
static instance of each singleton).

I don't think this is a particularily exotic thing to do.  It seemed
like a good, clean way to implement run-time loadable modules.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

>>>>> Mark Mitchell <mark@markmitchell.com>:

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

Jason> The current code uses timestamp ^ pid directly, without going
Jason> through the random number generator.  The code was lifted from
Jason> mkstemp in libiberty.

Jason> Really, this seems entirely adequate to me.  The number of
Jason> translation units that actually rely on this is small; witness
Jason> how long it took to fix this problem in the first place.

> Probably the current approach *is* good enough.  I was operating
> under the assumption that it wasn't, since HJ was concerned about
> it.

If this is the approach 1.1.1 uses on the thing that started this
thread (I'm not sure of I'm following the current discussion), this
test case will break it on linux:
	http://egcs.cygnus.com/ml/egcs-bugs/1999-02/msg00469.html

If the approach Jason lists above is the cause, the approach does not
seem adequate to me.  

What I'm doing in the real cause (not the test case) is putting self
registering singletons in .so files, and having them register
temselves with a central registry when the .so files are loaded (the
constructor of the singleton does the registration, and we create a
static instance of each singleton).

I don't think this is a particularily exotic thing to do.  It seemed
like a good, clean way to implement run-time loadable modules.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Mark Mitchell]

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


    Jason> The current code uses timestamp ^ pid directly, without
    Jason> going through the random number generator.  The code was
    Jason> lifted from mkstemp in libiberty.

    Jason> Really, this seems entirely adequate to me.  The number of
    Jason> translation units that actually rely on this is small;
    Jason> witness how long it took to fix this problem in the first
    Jason> place.

Probably the current approach *is* good enough.  I was operating under
the assumption that it wasn't, since HJ was concerned about it.  So, I
stand by my assertion that the right way to fix it, if it needs
fixing, is to add some random bits.  Of course, if ain't even broke,
then just leaving it be is fine, too!

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < u9ww1ii3mw.fsf@yorick.cygnus.com >you write:
  > The current code uses timestamp ^ pid directly, without going through the
  > random number generator.  The code was lifted from mkstemp in libiberty.
  > 
  > Really, this seems entirely adequate to me.  The number of translation
  > units that actually rely on this is small; witness how long it took to fix
  > this problem in the first place.
timestamp ^ pid seems quite reasonable to me too.  It's not 100% perfect, but
it is good enough IMHO.

So, what changes do I need to pull into egcs-1.1.2?

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
 > perfect, but it is good enough IMHO.

 > So, what changes do I need to pull into egcs-1.1.2?

Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>

        * tree.c (append_random_chars): New fn.
        (get_file_function_name_long): Use it.

It will need to be massaged a bit because 1.1.x doesn't have the change for
get_file_function_name_long, but that's not important.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
>  > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
>  > perfect, but it is good enough IMHO.
> 
>  > So, what changes do I need to pull into egcs-1.1.2?
> 
> Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
> 
>         * tree.c (append_random_chars): New fn.
>         (get_file_function_name_long): Use it.
> 
> It will need to be massaged a bit because 1.1.x doesn't have the change for
> get_file_function_name_long, but that's not important.
> 
> Jason

No matter what you use, please make sure ctors/dtors are local on
ELF.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10D8I7-00038sC@ocean.lucon.org >you write:
  > > 
  > > >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
  > > 
  > >  > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
  > >  > perfect, but it is good enough IMHO.
  > > 
  > >  > So, what changes do I need to pull into egcs-1.1.2?
  > > 
  > > Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
  > > 
  > >         * tree.c (append_random_chars): New fn.
  > >         (get_file_function_name_long): Use it.
  > > 
  > > It will need to be massaged a bit because 1.1.x doesn't have the change f
  > or
  > > get_file_function_name_long, but that's not important.
  > > 
  > > Jason
  > 
  > No matter what you use, please make sure ctors/dtors are local on
  > ELF.
Why is this necessary if we use Jason's patch?

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < m10D8I7-00038sC@ocean.lucon.org >you write:

 >> No matter what you use, please make sure ctors/dtors are local on
 >> ELF.

 > Why is this necessary if we use Jason's patch?

It isn't, but it doesn't hurt, either.  I don't see any need for it in
1.1.2, though.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
>  >   In message < m10D8I7-00038sC@ocean.lucon.org >you write:
> 
>  >> No matter what you use, please make sure ctors/dtors are local on
>  >> ELF.
> 
>  > Why is this necessary if we use Jason's patch?
> 
> It isn't, but it doesn't hurt, either.  I don't see any need for it in
> 1.1.2, though.
> 

You got it backward. Making ctors/dtors local on ELF FIXES the bug on
ELF. However, your patch won't hurt.

BTW, as far as file scope ctors/dtors on ELF are concerned, your patch
is not as good as making them local. This change will be in egcs
1.1.2/Linux.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
  > ELF. However, your patch won't hurt.
Yours works by introducing an ELF specific hack.

Jason's patch, while not 100% correct either is a lot closer than yours since
it works for a large number of targets instead of just ELF.  The cases where
it fails should be minimial as far as I can tell.

HJ, remember, we care about more than just Linux and ELF.  We have to.



jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
>   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>   > ELF. However, your patch won't hurt.
> Yours works by introducing an ELF specific hack.
> 
> Jason's patch, while not 100% correct either is a lot closer than yours since

Mine is 100% correct on ELF.

> it works for a large number of targets instead of just ELF.  The cases where
> it fails should be minimial as far as I can tell.
> 
> HJ, remember, we care about more than just Linux and ELF.  We have to.
> 

That is fine. But why cannot we have both? That way, ELF will be 100%
correct and others will be almost correct? For me, this discussion
makes few difference. I will make ELF 100% safe for Linux in anycase.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EJQj-000392C@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
  > >   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
  > >   > ELF. However, your patch won't hurt.
  > > Yours works by introducing an ELF specific hack.
  > > 
  > > Jason's patch, while not 100% correct either is a lot closer than yours s
  > ince
  > 
  > Mine is 100% correct on ELF.
And totally useless everywhere else.


  > That is fine. But why cannot we have both? That way, ELF will be 100%
  > correct and others will be almost correct? For me, this discussion
  > makes few difference. I will make ELF 100% safe for Linux in anycase.
Send me a patch and I'll consider it.  I will not accept a hack.



jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
>   In message < m10EJQj-000392C@ocean.lucon.org >you write:
>   > > 
>   > > 
>   > >   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>   > >   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>   > >   > ELF. However, your patch won't hurt.
>   > > Yours works by introducing an ELF specific hack.
>   > > 
>   > > Jason's patch, while not 100% correct either is a lot closer than yours s
>   > ince
>   > 
>   > Mine is 100% correct on ELF.
> And totally useless everywhere else.
> 

I won't go that far.

> 
>   > That is fine. But why cannot we have both? That way, ELF will be 100%
>   > correct and others will be almost correct? For me, this discussion
>   > makes few difference. I will make ELF 100% safe for Linux in anycase.
> Send me a patch and I'll consider it.  I will not accept a hack.
> 
> 
> 

Here it is.

-- 
H.J. Lu (hjl@gnu.org)
----
Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)

        * decl2.c (start_objects): Make file scope constructors and
        destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
        ASM_OUTPUT_DESTRUCTOR are defined.

--- ../../../../import/egcs/gcc/cp/decl2.c	Tue Nov 10 07:44:01 1998
+++ decl2.c	Sat Feb 20 11:32:58 1999
@@ -2943,6 +2943,11 @@ start_objects (method_type)
 					NULL_TREE),
 		  NULL_TREE, 0);
 
+#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
+  /* It can be a static function with .ctors/.dtors sections. */
+  TREE_PUBLIC (current_function_decl) = 0;
+#endif
+
   store_parm_decls ();
   pushlevel (0);
   clear_last_expr ();

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EJXX-000392C@ocean.lucon.org >you write:
  > Here it is.
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
  > 
  >         * decl2.c (start_objects): Make file scope constructors and
  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  >         ASM_OUTPUT_DESTRUCTOR are defined.
I don't think this patch is correct.

Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
that this patch wil work on COFF systems?





jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
>   In message < m10EJXX-000392C@ocean.lucon.org >you write:
>   > Here it is.
>   > 
>   > -- 
>   > H.J. Lu (hjl@gnu.org)
>   > ----
>   > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
>   > 
>   >         * decl2.c (start_objects): Make file scope constructors and
>   >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>   >         ASM_OUTPUT_DESTRUCTOR are defined.
> I don't think this patch is correct.
> 
> Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
> that this patch wil work on COFF systems?
> 

I know next to nothing about COFF and I have no access to any COFF
systems. I guess it is not hard to try it on a COFF system.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EJh1-000392C@ocean.lucon.org >you write:
  > > Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
  > > that this patch wil work on COFF systems?
  > > 
  > 
  > I know next to nothing about COFF and I have no access to any COFF
  > systems. I guess it is not hard to try it on a COFF system.
Which is precisely why this kind of patch is terribly dangerous and IMHO, not
really suitable for a minor release like egcs-1.1.2.

Will someone please test this patch on some COFF systems.

It absolutely can not and will not go in if we can not verify it does the
correct thing on COFF systems.



jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Robert Lipe]

>   > > Consider COFF systems which define ASM_OUTPUT_*.  Are you
>   > > absolutely sure that this patch wil work on COFF systems?
>   >
>   > I know next to nothing about COFF and I have no access to any COFF
>   > systems. I guess it is not hard to try it on a COFF system.
>
> Will someone please test this patch on some COFF systems.

I have ready access to an x86 COFF system.  OpenServer is both COFF and
ELF which might make it an interesting testsuite.  I should note that
OpenServer's COFF does define a multitude of ASM_OUTPUT_* operators.

If you can reach an agreement on exactly what needs to be tested and can
describe it concisely to me (not necessarily to the list), I'll spin a
bootstrap on one tree of your choosing (release or trunk) and run a set
of tests of your choosing.

Given the contention surrounding the failure modes and testcases, I'm
not about to walk into a battle.  Tell me exactly what you want tested
and I'll return true or false.

Clock cycles I have.   Appetite for a brawl I don't.

RJL

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 19990220153254.A8783@rjlhome.sco.com >you write:
  > If you can reach an agreement on exactly what needs to be tested and can
  > describe it concisely to me (not necessarily to the list), I'll spin a
  > bootstrap on one tree of your choosing (release or trunk) and run a set
  > of tests of your choosing.
I think the key is how do ctors/dtors fire for a shared library, both those
which appear on the link line and those which are explicitly loaded during
the execution of the program.

If the dynamic linker is responsible for firing them via .init sections or
similar mechanisms, then OpenServer would probably be fine with HJ's patch.


I'm going to sit down with this testcase from Steinar Bang and HJ's patch
for a few minutes too.  There's a voice inside my head that keeps telling me
I'm missing something with this whole discussion.


	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz


  > Clock cycles I have.   Appetite for a brawl I don't.
Well put.  That's what this is starting to turn into.  Deep breath time.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 19990220153254.A8783@rjlhome.sco.com >you write:
  > If you can reach an agreement on exactly what needs to be tested and can
  > describe it concisely to me (not necessarily to the list), I'll spin a
  > bootstrap on one tree of your choosing (release or trunk) and run a set
  > of tests of your choosing.
I think the key is how do ctors/dtors fire for a shared library, both those
which appear on the link line and those which are explicitly loaded during
the execution of the program.

If the dynamic linker is responsible for firing them via .init sections or
similar mechanisms, then OpenServer would probably be fine with HJ's patch.


I'm going to sit down with this testcase from Steinar Bang and HJ's patch
for a few minutes too.  There's a voice inside my head that keeps telling me
I'm missing something with this whole discussion.


	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz


  > Clock cycles I have.   Appetite for a brawl I don't.
Well put.  That's what this is starting to turn into.  Deep breath time.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Robert Lipe]

>   > > Consider COFF systems which define ASM_OUTPUT_*.  Are you
>   > > absolutely sure that this patch wil work on COFF systems?
>   >
>   > I know next to nothing about COFF and I have no access to any COFF
>   > systems. I guess it is not hard to try it on a COFF system.
>
> Will someone please test this patch on some COFF systems.

I have ready access to an x86 COFF system.  OpenServer is both COFF and
ELF which might make it an interesting testsuite.  I should note that
OpenServer's COFF does define a multitude of ASM_OUTPUT_* operators.

If you can reach an agreement on exactly what needs to be tested and can
describe it concisely to me (not necessarily to the list), I'll spin a
bootstrap on one tree of your choosing (release or trunk) and run a set
of tests of your choosing.

Given the contention surrounding the failure modes and testcases, I'm
not about to walk into a battle.  Tell me exactly what you want tested
and I'll return true or false.

Clock cycles I have.   Appetite for a brawl I don't.

RJL

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
>   In message < m10EJXX-000392C@ocean.lucon.org >you write:
>   > Here it is.
>   > 
>   > -- 
>   > H.J. Lu (hjl@gnu.org)
>   > ----
>   > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
>   > 
>   >         * decl2.c (start_objects): Make file scope constructors and
>   >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>   >         ASM_OUTPUT_DESTRUCTOR are defined.
> I don't think this patch is correct.
> 
> Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
> that this patch wil work on COFF systems?
> 

I know next to nothing about COFF and I have no access to any COFF
systems. I guess it is not hard to try it on a COFF system.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Sat, 20 Feb 1999, Jeffrey A Law wrote:
>In message < m10EJXX-000392C@ocean.lucon.org >you write:
>  > Here it is.
>  > 
>  > -- 
>  > H.J. Lu (hjl@gnu.org)
>  > ----
>  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
>  > 
>  >         * decl2.c (start_objects): Make file scope constructors and
>  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>  >         ASM_OUTPUT_DESTRUCTOR are defined.
>I don't think this patch is correct.
>
>Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
>that this patch wil work on COFF systems?
>

I tried it for DJGPP (which uses COFF) and initially didn't saw problems.
But anyway some more testing is required.  

Maybe it worth to add one additional macro to enable making file scope
constructors local

#if defined(ASM_OUTPUT_CONSTRUCTOR) && \
    defined(ASM_OUTPUT_DESTRUCTOR) && \
    defined(MAKE_SCOPE_CONSTRUCTORS_LOCAL)

Then we would be able to enable this feature only on systems we want it to 
be enabled.

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Sat, 20 Feb 1999, Jeffrey A Law wrote:
>In message < m10EJXX-000392C@ocean.lucon.org >you write:
>  > Here it is.
>  > 
>  > -- 
>  > H.J. Lu (hjl@gnu.org)
>  > ----
>  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
>  > 
>  >         * decl2.c (start_objects): Make file scope constructors and
>  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>  >         ASM_OUTPUT_DESTRUCTOR are defined.
>I don't think this patch is correct.
>
>Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
>that this patch wil work on COFF systems?
>

I tried it for DJGPP (which uses COFF) and initially didn't saw problems.
But anyway some more testing is required.  

Maybe it worth to add one additional macro to enable making file scope
constructors local

#if defined(ASM_OUTPUT_CONSTRUCTOR) && \
    defined(ASM_OUTPUT_DESTRUCTOR) && \
    defined(MAKE_SCOPE_CONSTRUCTORS_LOCAL)

Then we would be able to enable this feature only on systems we want it to 
be enabled.

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EJXX-000392C@ocean.lucon.org >you write:
  > Here it is.
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
  > 
  >         * decl2.c (start_objects): Make file scope constructors and
  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  >         ASM_OUTPUT_DESTRUCTOR are defined.
I don't think this patch is correct.

Consider COFF systems which define ASM_OUTPUT_*.  Are you absolutely sure
that this patch wil work on COFF systems?





jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EJXX-000392C@ocean.lucon.org >you write:
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
  > 
  >         * decl2.c (start_objects): Make file scope constructors and
  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  >         ASM_OUTPUT_DESTRUCTOR are defined.
Note this patch also effects Windows/NT and VMS (alpha & dec).

IMHO, it does not belong in egcs-1.1.2.  It's simply too dangerous.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EJXX-000392C@ocean.lucon.org >you write:
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)
  > 
  >         * decl2.c (start_objects): Make file scope constructors and
  >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  >         ASM_OUTPUT_DESTRUCTOR are defined.
Note this patch also effects Windows/NT and VMS (alpha & dec).

IMHO, it does not belong in egcs-1.1.2.  It's simply too dangerous.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Mumit Khan]

On Sat, 20 Feb 1999, H.J. Lu wrote:

>  
> +#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
> +  /* It can be a static function with .ctors/.dtors sections. */
> +  TREE_PUBLIC (current_function_decl) = 0;
> +#endif
> +

Whoa, this affects other systems besides ELF, so let's please be careful!
I know for sure it affects windows32 PE-COFF systems, and possibly all the
other COFF'ish systems as well.

I'll try it out locally to see the effect on windows32, but only on my dev 
branch, not 1.1.2 branch.

Regards,
Mumit

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Mumit Khan]

On Sat, 20 Feb 1999, H.J. Lu wrote:

>  
> +#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
> +  /* It can be a static function with .ctors/.dtors sections. */
> +  TREE_PUBLIC (current_function_decl) = 0;
> +#endif
> +

Whoa, this affects other systems besides ELF, so let's please be careful!
I know for sure it affects windows32 PE-COFF systems, and possibly all the
other COFF'ish systems as well.

I'll try it out locally to see the effect on windows32, but only on my dev 
branch, not 1.1.2 branch.

Regards,
Mumit

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

>         * decl2.c (start_objects): Make file scope constructors and
>         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>         ASM_OUTPUT_DESTRUCTOR are defined.

This is incorrect. Please look at config/aoutos.h. It always defines
ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
and collect2 would have to find constructors. Now that you made them
static, this would fail.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >         * decl2.c (start_objects): Make file scope constructors and
> >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
> >         ASM_OUTPUT_DESTRUCTOR are defined.
> 
> This is incorrect. Please look at config/aoutos.h. It always defines
> ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
> GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
> and collect2 would have to find constructors. Now that you made them
> static, this would fail.
> 

That is bogus. Please take a look at how ASM_OUTPUT_CONSTRUCTOR is
used. If ASM_OUTPUT_CONSTRUCTOR is not defined, egcs will check whether
to use the gnu linker. Why does config/aoutos.h to have duplicate
what is in the egcs backend?

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EMUB-000392C@ocean.lucon.org >you write:
  > > 
  > > >         * decl2.c (start_objects): Make file scope constructors and
  > > >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  > > >         ASM_OUTPUT_DESTRUCTOR are defined.
  > > 
  > > This is incorrect. Please look at config/aoutos.h. It always defines
  > > ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
  > > GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
  > > and collect2 would have to find constructors. Now that you made them
  > > static, this would fail.
  > > 
  > 
  > That is bogus. Please take a look at how ASM_OUTPUT_CONSTRUCTOR is
  > used. If ASM_OUTPUT_CONSTRUCTOR is not defined, egcs will check whether
  > to use the gnu linker. Why does config/aoutos.h to have duplicate
  > what is in the egcs backend?
I think you missed the most critical point behind Martin's objection.

Your change, as-is will break a port.

You need to address this problem in some manner (I think there have been
suggestions posted to the list).

There's still the issue of breaking NT, VMS and a variety of COFF systems
too with your patch.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EMUB-000392C@ocean.lucon.org >you write:
  > > 
  > > >         * decl2.c (start_objects): Make file scope constructors and
  > > >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
  > > >         ASM_OUTPUT_DESTRUCTOR are defined.
  > > 
  > > This is incorrect. Please look at config/aoutos.h. It always defines
  > > ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
  > > GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
  > > and collect2 would have to find constructors. Now that you made them
  > > static, this would fail.
  > > 
  > 
  > That is bogus. Please take a look at how ASM_OUTPUT_CONSTRUCTOR is
  > used. If ASM_OUTPUT_CONSTRUCTOR is not defined, egcs will check whether
  > to use the gnu linker. Why does config/aoutos.h to have duplicate
  > what is in the egcs backend?
I think you missed the most critical point behind Martin's objection.

Your change, as-is will break a port.

You need to address this problem in some manner (I think there have been
suggestions posted to the list).

There's still the issue of breaking NT, VMS and a variety of COFF systems
too with your patch.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >         * decl2.c (start_objects): Make file scope constructors and
> >         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
> >         ASM_OUTPUT_DESTRUCTOR are defined.
> 
> This is incorrect. Please look at config/aoutos.h. It always defines
> ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
> GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
> and collect2 would have to find constructors. Now that you made them
> static, this would fail.
> 

That is bogus. Please take a look at how ASM_OUTPUT_CONSTRUCTOR is
used. If ASM_OUTPUT_CONSTRUCTOR is not defined, egcs will check whether
to use the gnu linker. Why does config/aoutos.h to have duplicate
what is in the egcs backend?

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

>         * decl2.c (start_objects): Make file scope constructors and
>         destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
>         ASM_OUTPUT_DESTRUCTOR are defined.

This is incorrect. Please look at config/aoutos.h. It always defines
ASM_OUTPUT_CONSTRUCTOR, but then decides, at runtime, whether to use
GNU binutils. If GNU ld is not used, no __CTOR_LIST__ is constructed,
and collect2 would have to find constructors. Now that you made them
static, this would fail.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

 > +#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
 > +  /* It can be a static function with .ctors/.dtors sections. */
 > +  TREE_PUBLIC (current_function_decl) = 0;
 > +#endif

This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
imply the use of .ctors/.dtors sections.  As someone else mentioned,
aoutos.h defines it to a conditional, though there's really no reason for
that; the code in aoutos.h is a duplicate of the code in
assemble_constructor.  I think this approach will work if we remove the
aoutos.h definition and add a note to tm.texi that ASM_OUTPUT_CONSTRUCTOR
does not rely on the name being exported, and that it is unconditional.

While we're at it, we should reduce the redundancy of the tm files; there
are too many files with the same defn of ASM_OUTPUT_CONSTRUCTOR.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
  > This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
  > imply the use of .ctors/.dtors sections.
Right.  That's why trying to if this problem by depending on that macro is
wrong.  

It sounds like we need a new macro which indicates the target uses ctor/dtor
sections and the dynamic linker handles firing of ctors/dtors.  Given such
a macro.

  > As someone else mentioned,
  > aoutos.h defines it to a conditional, though there's really no reason for
  > that; the code in aoutos.h is a duplicate of the code in
  > assemble_constructor.  I think this approach will work if we remove the
  > aoutos.h definition and add a note to tm.texi that ASM_OUTPUT_CONSTRUCTOR
  > does not rely on the name being exported, and that it is unconditional.
  > 
  > While we're at it, we should reduce the redundancy of the tm files; there
  > are too many files with the same defn of ASM_OUTPUT_CONSTRUCTOR.
Yea.  But fixing aoutos.h does not (IMHO) make HJ's patch correct since it
really sounds like he's depending on the wrong macro to control the behavior
he wants.

I'll fix aoutos.h in the mainline tree.


jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

[ replying to my own ill-formed message ]

  In message < 7817.919639310@hurl.cygnus.com > I write:

  >   In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
  >   > This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
  >   > imply the use of .ctors/.dtors sections.
  > Right.  That's why trying to if this problem by depending on that macro is
  > wrong.  
			         ^^^ fix

  > It sounds like we need a new macro which indicates the target uses
  > ctor/dtor sections and the dynamic linker handles firing of ctors/dtors.
  > Given such a macro.
Given such a macro, we can safely make these functions static on those systems
where it is safe.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

[ replying to my own ill-formed message ]

  In message < 7817.919639310@hurl.cygnus.com > I write:

  >   In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
  >   > This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
  >   > imply the use of .ctors/.dtors sections.
  > Right.  That's why trying to if this problem by depending on that macro is
  > wrong.  
			         ^^^ fix

  > It sounds like we need a new macro which indicates the target uses
  > ctor/dtor sections and the dynamic linker handles firing of ctors/dtors.
  > Given such a macro.
Given such a macro, we can safely make these functions static on those systems
where it is safe.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
 >> This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
 >> imply the use of .ctors/.dtors sections.

 > Right.  That's why trying to fix this problem by depending on that macro
 > is wrong.

 > It sounds like we need a new macro which indicates the target uses
 > ctor/dtor sections and the dynamic linker handles firing of ctors/dtors.
 > Given such a macro, we can safely make these functions static on those
 > systems where it is safe.

I think ASM_OUTPUT_CONSTRUCTOR can be that macro, if we change the
documentation; it looks like the aoutos.h version was the only one that
would break with HJ's patch.  All the definitions for COFF and such
targets looked fine; they also rely on the value of the symbol within the
translation unit rather than having it available to the linker.  We only
need the symbols to be public if we're using collect.

Having another macro would also be fine, and would allow for runtime
selection.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < u9lnhrfg3k.fsf@yorick.cygnus.com >you write:
  > I think ASM_OUTPUT_CONSTRUCTOR can be that macro, if we change the
  > documentation; it looks like the aoutos.h version was the only one that
  > would break with HJ's patch. 

  > All the definitions for COFF and such
  > targets looked fine; they also rely on the value of the symbol within the
  > translation unit rather than having it available to the linker.  We only
  > need the symbols to be public if we're using collect.
Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTOR?

A private discussion with Robert Lipe leads me to believe the change is
OK for SCO and its close relatives.  I haven't a clue about other COFF targets.


  > Having another macro would also be fine, and would allow for runtime
  > selection.
Well, if we can easily make the existing macro safe, I'm all for that.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Richard Henderson]

On Sun, Feb 21, 1999 at 05:40:09PM -0700, Jeffrey A Law wrote:
> Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTOR?

Yes.  Except for that one aout anomaly, they all work by placing a
pointer in a section.  We should always be able to make the symbol
referenced by that pointer local.


r~

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 19990221170738.A22156@cygnus.com >you write:
  > On Sun, Feb 21, 1999 at 05:40:09PM -0700, Jeffrey A Law wrote:
  > > Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTO
  > R?
  > 
  > Yes.  Except for that one aout anomaly, they all work by placing a
  > pointer in a section.  We should always be able to make the symbol
  > referenced by that pointer local.
OK.  So we fix aoutos.h apply HJ's patch, & update the docs.  This fixes
ELF & COFF.

Then we backport Jason's October changes to add random chars to mitigate
these problems on other platforms.

Then we can close this issue right?

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 19990221170738.A22156@cygnus.com >you write:
  > On Sun, Feb 21, 1999 at 05:40:09PM -0700, Jeffrey A Law wrote:
  > > Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTO
  > R?
  > 
  > Yes.  Except for that one aout anomaly, they all work by placing a
  > pointer in a section.  We should always be able to make the symbol
  > referenced by that pointer local.
OK.  So we fix aoutos.h apply HJ's patch, & update the docs.  This fixes
ELF & COFF.

Then we backport Jason's October changes to add random chars to mitigate
these problems on other platforms.

Then we can close this issue right?

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Richard Henderson]

On Sun, Feb 21, 1999 at 05:40:09PM -0700, Jeffrey A Law wrote:
> Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTOR?

Yes.  Except for that one aout anomaly, they all work by placing a
pointer in a section.  We should always be able to make the symbol
referenced by that pointer local.


r~

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < u9lnhrfg3k.fsf@yorick.cygnus.com >you write:
  > I think ASM_OUTPUT_CONSTRUCTOR can be that macro, if we change the
  > documentation; it looks like the aoutos.h version was the only one that
  > would break with HJ's patch. 

  > All the definitions for COFF and such
  > targets looked fine; they also rely on the value of the symbol within the
  > translation unit rather than having it available to the linker.  We only
  > need the symbols to be public if we're using collect.
Really?  Including NT and VMS which also define the ASM_OUTPUT_CONSTRUCTOR?

A private discussion with Robert Lipe leads me to believe the change is
OK for SCO and its close relatives.  I haven't a clue about other COFF targets.


  > Having another macro would also be fine, and would allow for runtime
  > selection.
Well, if we can easily make the existing macro safe, I'm all for that.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
 >> This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
 >> imply the use of .ctors/.dtors sections.

 > Right.  That's why trying to fix this problem by depending on that macro
 > is wrong.

 > It sounds like we need a new macro which indicates the target uses
 > ctor/dtor sections and the dynamic linker handles firing of ctors/dtors.
 > Given such a macro, we can safely make these functions static on those
 > systems where it is safe.

I think ASM_OUTPUT_CONSTRUCTOR can be that macro, if we change the
documentation; it looks like the aoutos.h version was the only one that
would break with HJ's patch.  All the definitions for COFF and such
targets looked fine; they also rely on the value of the symbol within the
translation unit rather than having it available to the linker.  We only
need the symbols to be public if we're using collect.

Having another macro would also be fine, and would allow for runtime
selection.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < u9vhgvfmfa.fsf@yorick.cygnus.com >you write:
  > This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
  > imply the use of .ctors/.dtors sections.
Right.  That's why trying to if this problem by depending on that macro is
wrong.  

It sounds like we need a new macro which indicates the target uses ctor/dtor
sections and the dynamic linker handles firing of ctors/dtors.  Given such
a macro.

  > As someone else mentioned,
  > aoutos.h defines it to a conditional, though there's really no reason for
  > that; the code in aoutos.h is a duplicate of the code in
  > assemble_constructor.  I think this approach will work if we remove the
  > aoutos.h definition and add a note to tm.texi that ASM_OUTPUT_CONSTRUCTOR
  > does not rely on the name being exported, and that it is unconditional.
  > 
  > While we're at it, we should reduce the redundancy of the tm files; there
  > are too many files with the same defn of ASM_OUTPUT_CONSTRUCTOR.
Yea.  But fixing aoutos.h does not (IMHO) make HJ's patch correct since it
really sounds like he's depending on the wrong macro to control the behavior
he wants.

I'll fix aoutos.h in the mainline tree.


jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

 > +#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
 > +  /* It can be a static function with .ctors/.dtors sections. */
 > +  TREE_PUBLIC (current_function_decl) = 0;
 > +#endif

This is wrong, or at least incomplete.  ASM_OUTPUT_CONSTRUCTOR does not
imply the use of .ctors/.dtors sections.  As someone else mentioned,
aoutos.h defines it to a conditional, though there's really no reason for
that; the code in aoutos.h is a duplicate of the code in
assemble_constructor.  I think this approach will work if we remove the
aoutos.h definition and add a note to tm.texi that ASM_OUTPUT_CONSTRUCTOR
does not rely on the name being exported, and that it is unconditional.

While we're at it, we should reduce the redundancy of the tm files; there
are too many files with the same defn of ASM_OUTPUT_CONSTRUCTOR.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
>   In message < m10EJQj-000392C@ocean.lucon.org >you write:
>   > > 
>   > > 
>   > >   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>   > >   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>   > >   > ELF. However, your patch won't hurt.
>   > > Yours works by introducing an ELF specific hack.
>   > > 
>   > > Jason's patch, while not 100% correct either is a lot closer than yours s
>   > ince
>   > 
>   > Mine is 100% correct on ELF.
> And totally useless everywhere else.
> 

I won't go that far.

> 
>   > That is fine. But why cannot we have both? That way, ELF will be 100%
>   > correct and others will be almost correct? For me, this discussion
>   > makes few difference. I will make ELF 100% safe for Linux in anycase.
> Send me a patch and I'll consider it.  I will not accept a hack.
> 
> 
> 

Here it is.

-- 
H.J. Lu (hjl@gnu.org)
----
Fri Jan 29 19:02:50 1999  H.J. Lu  (hjl@gnu.org)

        * decl2.c (start_objects): Make file scope constructors and
        destructors local to the file if ASM_OUTPUT_CONSTRUCTOR and
        ASM_OUTPUT_DESTRUCTOR are defined.

--- ../../../../import/egcs/gcc/cp/decl2.c	Tue Nov 10 07:44:01 1998
+++ decl2.c	Sat Feb 20 11:32:58 1999
@@ -2943,6 +2943,11 @@ start_objects (method_type)
 					NULL_TREE),
 		  NULL_TREE, 0);
 
+#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
+  /* It can be a static function with .ctors/.dtors sections. */
+  TREE_PUBLIC (current_function_decl) = 0;
+#endif
+
   store_parm_decls ();
   pushlevel (0);
   clear_last_expr ();

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EJQj-000392C@ocean.lucon.org >you write:
  > > 
  > > 
  > >   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
  > >   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
  > >   > ELF. However, your patch won't hurt.
  > > Yours works by introducing an ELF specific hack.
  > > 
  > > Jason's patch, while not 100% correct either is a lot closer than yours s
  > ince
  > 
  > Mine is 100% correct on ELF.
And totally useless everywhere else.


  > That is fine. But why cannot we have both? That way, ELF will be 100%
  > correct and others will be almost correct? For me, this discussion
  > makes few difference. I will make ELF 100% safe for Linux in anycase.
Send me a patch and I'll consider it.  I will not accept a hack.



jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
>   In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>   > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>   > ELF. However, your patch won't hurt.
> Yours works by introducing an ELF specific hack.
> 
> Jason's patch, while not 100% correct either is a lot closer than yours since

Mine is 100% correct on ELF.

> it works for a large number of targets instead of just ELF.  The cases where
> it fails should be minimial as far as I can tell.
> 
> HJ, remember, we care about more than just Linux and ELF.  We have to.
> 

That is fine. But why cannot we have both? That way, ELF will be 100%
correct and others will be almost correct? For me, this discussion
makes few difference. I will make ELF 100% safe for Linux in anycase.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> HJ, remember, we care about more than just Linux and ELF.  We have to.
> 

Jeff, please remember egcs is/will be the "vendor" compiler for Linux.
There is no excuse not to make it 100% correct on Linux if we can.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EJTY-000392C@ocean.lucon.org >you write:
  > > HJ, remember, we care about more than just Linux and ELF.  We have to.
  > > 
  > 
  > Jeff, please remember egcs is/will be the "vendor" compiler for Linux.
  > There is no excuse not to make it 100% correct on Linux if we can.
There is NO excuse for a hack.  Period.  I will not install a hack.  Period.

If you submit a clean patch I will consider it.

Every release we go through this with one of your pet patches.  And
consistently we find that your "this must go into this release" patch is
bogus, either because it is a hack or because it really doesn't solve the
problem.

Thus, I will not commit to installing your change until I actually see it.

Submit a patch and I will consider it.  Otherwise, stop wasting my time.


jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> Thus, I will not commit to installing your change until I actually see it.
> 

Just for the record, The patch I sent out today is the same as

http://www.cygnus.com/ml/egcs/1999-Jan/1168.html

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> Just for the record, The patch I sent out today is the same as
> 
> http://www.cygnus.com/ml/egcs/1999-Jan/1168.html

Unfortunately, it is as incorrect today as it was then.

Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> Just for the record, The patch I sent out today is the same as
> 
> http://www.cygnus.com/ml/egcs/1999-Jan/1168.html

Unfortunately, it is as incorrect today as it was then.

Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> Thus, I will not commit to installing your change until I actually see it.
> 

Just for the record, The patch I sent out today is the same as

http://www.cygnus.com/ml/egcs/1999-Jan/1168.html

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10EJTY-000392C@ocean.lucon.org >you write:
  > > HJ, remember, we care about more than just Linux and ELF.  We have to.
  > > 
  > 
  > Jeff, please remember egcs is/will be the "vendor" compiler for Linux.
  > There is no excuse not to make it 100% correct on Linux if we can.
There is NO excuse for a hack.  Period.  I will not install a hack.  Period.

If you submit a clean patch I will consider it.

Every release we go through this with one of your pet patches.  And
consistently we find that your "this must go into this release" patch is
bogus, either because it is a hack or because it really doesn't solve the
problem.

Thus, I will not commit to installing your change until I actually see it.

Submit a patch and I will consider it.  Otherwise, stop wasting my time.


jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> HJ, remember, we care about more than just Linux and ELF.  We have to.
> 

Jeff, please remember egcs is/will be the "vendor" compiler for Linux.
There is no excuse not to make it 100% correct on Linux if we can.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Zack Weinberg]

On Sat, 20 Feb 1999 13:46:26 -0700, Jeffrey A Law wrote:
>
>  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>  > ELF. However, your patch won't hurt.
>Yours works by introducing an ELF specific hack.
>
>Jason's patch, while not 100% correct either is a lot closer than yours since
>it works for a large number of targets instead of just ELF.  The cases where
>it fails should be minimial as far as I can tell.
>
>HJ, remember, we care about more than just Linux and ELF.  We have to.

I don't really see using local symbols for constructors as an
ELF-specific hack.  HJ's implementation may be ELF-specific, but we
ought to be able to use the same tactic on any system with named
sections - at least XCOFF, and I know there are others.

zw

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902202057.PAA22565@blastula.phys.columbia.edu >you write:
  > I don't really see using local symbols for constructors as an
  > ELF-specific hack.  HJ's implementation may be ELF-specific, but we
  > ought to be able to use the same tactic on any system with named
  > sections - at least XCOFF, and I know there are others.
Huh?  Just because a target has named sections does not mean it has functional
init/fini support.  Doesn't making the ctors/dtors static depend on functional
init/fini support, particularly for shared libraries?

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Zack Weinberg]

On Sat, 20 Feb 1999 14:27:02 -0700, Jeffrey A Law wrote:
>
>  In message < 199902202057.PAA22565@blastula.phys.columbia.edu >you write:
>  > I don't really see using local symbols for constructors as an
>  > ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>  > ought to be able to use the same tactic on any system with named
>  > sections - at least XCOFF, and I know there are others.
>Huh?  Just because a target has named sections does not mean it has functional
>init/fini support.  Doesn't making the ctors/dtors static depend on functional
>init/fini support, particularly for shared libraries?

Yes, but I thought that all it takes to have functional init/fini was
named sections and a sensible dynamic linker.  I don't claim to know
this issue inside out, but I do know there used to be plenty of
targets for which basic ctors and dtors would work without collect2,
which meant they had functional init/fini - right?

zw

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902202135.QAA23017@blastula.phys.columbia.edu >you write:
  > Yes, but I thought that all it takes to have functional init/fini was
  > named sections and a sensible dynamic linker.
Sensible dynamic linker is where some systems start to fall down :(  I know
of at least one where we have named sections, but the dynamic linker support
for initializers and finalizers is too braindamaged to be useful (HPUX).  There
may be others.  For example, I would worry about AIX/XCOFF.

  > I don't claim to know
  > this issue inside out, but I do know there used to be plenty of
  > targets for which basic ctors and dtors would work without collect2,
  > which meant they had functional init/fini - right?
Not necessarily.  Some of those systems worked because the GNU linker did
the collecting instead of collect2.

I believe the GNU linker could either look at the symbol names or magic stabs
(cough cough) to get a list of routines to put in __CTOR_LIST__ and
__DTOR_LIST__.





jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902202135.QAA23017@blastula.phys.columbia.edu >you write:
  > Yes, but I thought that all it takes to have functional init/fini was
  > named sections and a sensible dynamic linker.
Sensible dynamic linker is where some systems start to fall down :(  I know
of at least one where we have named sections, but the dynamic linker support
for initializers and finalizers is too braindamaged to be useful (HPUX).  There
may be others.  For example, I would worry about AIX/XCOFF.

  > I don't claim to know
  > this issue inside out, but I do know there used to be plenty of
  > targets for which basic ctors and dtors would work without collect2,
  > which meant they had functional init/fini - right?
Not necessarily.  Some of those systems worked because the GNU linker did
the collecting instead of collect2.

I believe the GNU linker could either look at the symbol names or magic stabs
(cough cough) to get a list of routines to put in __CTOR_LIST__ and
__DTOR_LIST__.





jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> Yes, but I thought that all it takes to have functional init/fini was
> named sections and a sensible dynamic linker.  I don't claim to know
> this issue inside out, but I do know there used to be plenty of
> targets for which basic ctors and dtors would work without collect2,
> which meant they had functional init/fini - right?

Indeed. However, it seems to be non-trivial to find out in gcc whether
we are using such a target.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Kamil Iskra]

On Sun, 21 Feb 1999, Martin v. Loewis wrote:

> > Yes, but I thought that all it takes to have functional init/fini was
> > named sections and a sensible dynamic linker.  I don't claim to know
> > this issue inside out, but I do know there used to be plenty of
> > targets for which basic ctors and dtors would work without collect2,
> > which meant they had functional init/fini - right?
> Indeed. However, it seems to be non-trivial to find out in gcc whether
> we are using such a target.

I don't get it. What's so difficult about introducing a new target macro
that conveys precisely this information?

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> I don't get it. What's so difficult about introducing a new target macro
> that conveys precisely this information?

That is certainly possible. Maybe not for 1.1.2, though...

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> I don't get it. What's so difficult about introducing a new target macro
> that conveys precisely this information?

That is certainly possible. Maybe not for 1.1.2, though...

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Kamil Iskra]

On Sun, 21 Feb 1999, Martin v. Loewis wrote:

> > Yes, but I thought that all it takes to have functional init/fini was
> > named sections and a sensible dynamic linker.  I don't claim to know
> > this issue inside out, but I do know there used to be plenty of
> > targets for which basic ctors and dtors would work without collect2,
> > which meant they had functional init/fini - right?
> Indeed. However, it seems to be non-trivial to find out in gcc whether
> we are using such a target.

I don't get it. What's so difficult about introducing a new target macro
that conveys precisely this information?

/ Kamil Iskra    AmigaOS  Linux/i386  Linux/m68k               \
| GeekGadgets m68k-amigaos GCC maintainer                      |
| iskra@student.uci.agh.edu.pl  kiskra@ernie.icslab.agh.edu.pl |
\ kamil@dwd.interkom.pl   http://student.uci.agh.edu.pl/~iskra /

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> Yes, but I thought that all it takes to have functional init/fini was
> named sections and a sensible dynamic linker.  I don't claim to know
> this issue inside out, but I do know there used to be plenty of
> targets for which basic ctors and dtors would work without collect2,
> which meant they had functional init/fini - right?

Indeed. However, it seems to be non-trivial to find out in gcc whether
we are using such a target.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Zack Weinberg]

On Sat, 20 Feb 1999 14:27:02 -0700, Jeffrey A Law wrote:
>
>  In message < 199902202057.PAA22565@blastula.phys.columbia.edu >you write:
>  > I don't really see using local symbols for constructors as an
>  > ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>  > ought to be able to use the same tactic on any system with named
>  > sections - at least XCOFF, and I know there are others.
>Huh?  Just because a target has named sections does not mean it has functional
>init/fini support.  Doesn't making the ctors/dtors static depend on functional
>init/fini support, particularly for shared libraries?

Yes, but I thought that all it takes to have functional init/fini was
named sections and a sensible dynamic linker.  I don't claim to know
this issue inside out, but I do know there used to be plenty of
targets for which basic ctors and dtors would work without collect2,
which meant they had functional init/fini - right?

zw

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[the jackal]

Warning
Could not process message with given Content-Type: 
multipart/signed; boundary=z6Eq5LdranGa6ru8; micalg=pgp-md5;protocol="application/pgp-signature"

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 19990221211950.B10271@diwanh.stu.rpi.edu >you write:
  > Jeff et al:
  > 	Is there not a symbol for ELF so as to allow conditional compilation?
  > That way, Mr. Lu's changes may be incorporated under an #ifdef and not
  > effect anything else in the compiler.
No, and adding such a symbol and using it for this test is the wrong approach
to solving this kind of problem.

Instead of saying "it works in ELF", ask yourself the question, what
characteristics of ELF make such a change desirable.

That is how we manage to write a compiler that works across a huge variety of
targets, object file formats, debug formats, host & build systems, etc.


jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 19990221211950.B10271@diwanh.stu.rpi.edu >you write:
  > Jeff et al:
  > 	Is there not a symbol for ELF so as to allow conditional compilation?
  > That way, Mr. Lu's changes may be incorporated under an #ifdef and not
  > effect anything else in the compiler.
No, and adding such a symbol and using it for this test is the wrong approach
to solving this kind of problem.

Instead of saying "it works in ELF", ask yourself the question, what
characteristics of ELF make such a change desirable.

That is how we manage to write a compiler that works across a huge variety of
targets, object file formats, debug formats, host & build systems, etc.


jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[the jackal]

Jeff et al:
	Is there not a symbol for ELF so as to allow conditional compilation? That way, Mr. Lu's changes may be incorporated under an #ifdef and not effect anything else in the compiler.

On Sat, Feb 20, 1999 at 02:27:02PM -0700, Jeffrey A Law wrote:
> Huh?  Just because a target has named sections does not mean it has functional
> init/fini support.  Doesn't making the ctors/dtors static depend on functional
> init/fini support, particularly for shared libraries?

-- 
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a

iQCVAwUBNtC+xQ6sg/oMyISxAQFE/wP/SnOabXtbIMQ652H/Oi+ZV48e0LgwnmM5
YHFo+myUyEzn573rzxIfJmMvNzovGR69BOs0pBaiii2+XKZH2RkTMD2gzKsaJ0ym
bRGi05ibkbPE8PG6yNwybd7rwbuwFHg8BVPtigj1OFNQ4Wuux4OBxfJhbLxQ8XTS
GpPmYEx7VGY=
=Lp/U
-----END PGP SIGNATURE-----

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902202057.PAA22565@blastula.phys.columbia.edu >you write:
  > I don't really see using local symbols for constructors as an
  > ELF-specific hack.  HJ's implementation may be ELF-specific, but we
  > ought to be able to use the same tactic on any system with named
  > sections - at least XCOFF, and I know there are others.
Huh?  Just because a target has named sections does not mean it has functional
init/fini support.  Doesn't making the ctors/dtors static depend on functional
init/fini support, particularly for shared libraries?

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Sat, 20 Feb 1999, Zack Weinberg wrote:
>On Sat, 20 Feb 1999 13:46:26 -0700, Jeffrey A Law wrote:
>>
>>  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>>  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>>  > ELF. However, your patch won't hurt.
>>Yours works by introducing an ELF specific hack.
>>
>>Jason's patch, while not 100% correct either is a lot closer than yours since
>>it works for a large number of targets instead of just ELF.  The cases where
>>it fails should be minimial as far as I can tell.
>>
>>HJ, remember, we care about more than just Linux and ELF.  We have to.
>
>I don't really see using local symbols for constructors as an
>ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>ought to be able to use the same tactic on any system with named
>sections - at least XCOFF, and I know there are others.
>

I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
problems but anyway it is not carefully tested yet.

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> >
> >I don't really see using local symbols for constructors as an
> >ELF-specific hack.  HJ's implementation may be ELF-specific, but we
> >ought to be able to use the same tactic on any system with named
> >sections - at least XCOFF, and I know there are others.
> >
> 
> I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
> problems but anyway it is not carefully tested yet.
> 

Assume your test is right, you will see the problem if there is one.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Mon, 22 Feb 1999, H.J. Lu wrote:
>> >
>> >I don't really see using local symbols for constructors as an
>> >ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>> >ought to be able to use the same tactic on any system with named
>> >sections - at least XCOFF, and I know there are others.
>> >
>> 
>> I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
>> problems but anyway it is not carefully tested yet.
>> 
>
>Assume your test is right, you will see the problem if there is one.
>

At that time I built 1.1.2pre1 with this patch and did only some very
preliminary tests. Now I tried it for my own applications and with some tests
I had and seems that all is Ok for DJGPP (Note that rather serious 
patches are required to build these version for DJGPP)

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Mon, 22 Feb 1999, H.J. Lu wrote:
>> >
>> >I don't really see using local symbols for constructors as an
>> >ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>> >ought to be able to use the same tactic on any system with named
>> >sections - at least XCOFF, and I know there are others.
>> >
>> 
>> I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
>> problems but anyway it is not carefully tested yet.
>> 
>
>Assume your test is right, you will see the problem if there is one.
>

At that time I built 1.1.2pre1 with this patch and did only some very
preliminary tests. Now I tried it for my own applications and with some tests
I had and seems that all is Ok for DJGPP (Note that rather serious 
patches are required to build these version for DJGPP)

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> >
> >I don't really see using local symbols for constructors as an
> >ELF-specific hack.  HJ's implementation may be ELF-specific, but we
> >ought to be able to use the same tactic on any system with named
> >sections - at least XCOFF, and I know there are others.
> >
> 
> I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
> problems but anyway it is not carefully tested yet.
> 

Assume your test is right, you will see the problem if there is one.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Andris Pavenis]

On Sat, 20 Feb 1999, Zack Weinberg wrote:
>On Sat, 20 Feb 1999 13:46:26 -0700, Jeffrey A Law wrote:
>>
>>  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>>  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>>  > ELF. However, your patch won't hurt.
>>Yours works by introducing an ELF specific hack.
>>
>>Jason's patch, while not 100% correct either is a lot closer than yours since
>>it works for a large number of targets instead of just ELF.  The cases where
>>it fails should be minimial as far as I can tell.
>>
>>HJ, remember, we care about more than just Linux and ELF.  We have to.
>
>I don't really see using local symbols for constructors as an
>ELF-specific hack.  HJ's implementation may be ELF-specific, but we
>ought to be able to use the same tactic on any system with named
>sections - at least XCOFF, and I know there are others.
>

I tried it also for DJGPP with egcs-1.1.2-pre1. Initially I didn't saw any
problems but anyway it is not carefully tested yet.

Andris

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Zack Weinberg]

On Sat, 20 Feb 1999 13:46:26 -0700, Jeffrey A Law wrote:
>
>  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
>  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
>  > ELF. However, your patch won't hurt.
>Yours works by introducing an ELF specific hack.
>
>Jason's patch, while not 100% correct either is a lot closer than yours since
>it works for a large number of targets instead of just ELF.  The cases where
>it fails should be minimial as far as I can tell.
>
>HJ, remember, we care about more than just Linux and ELF.  We have to.

I don't really see using local symbols for constructors as an
ELF-specific hack.  HJ's implementation may be ELF-specific, but we
ought to be able to use the same tactic on any system with named
sections - at least XCOFF, and I know there are others.

zw

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10DUeS-00038sC@ocean.lucon.org >you write:
  > You got it backward. Making ctors/dtors local on ELF FIXES the bug on
  > ELF. However, your patch won't hurt.
Yours works by introducing an ELF specific hack.

Jason's patch, while not 100% correct either is a lot closer than yours since
it works for a large number of targets instead of just ELF.  The cases where
it fails should be minimial as far as I can tell.

HJ, remember, we care about more than just Linux and ELF.  We have to.



jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
>  >   In message < m10D8I7-00038sC@ocean.lucon.org >you write:
> 
>  >> No matter what you use, please make sure ctors/dtors are local on
>  >> ELF.
> 
>  > Why is this necessary if we use Jason's patch?
> 
> It isn't, but it doesn't hurt, either.  I don't see any need for it in
> 1.1.2, though.
> 

You got it backward. Making ctors/dtors local on ELF FIXES the bug on
ELF. However, your patch won't hurt.

BTW, as far as file scope ctors/dtors on ELF are concerned, your patch
is not as good as making them local. This change will be in egcs
1.1.2/Linux.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < m10D8I7-00038sC@ocean.lucon.org >you write:

 >> No matter what you use, please make sure ctors/dtors are local on
 >> ELF.

 > Why is this necessary if we use Jason's patch?

It isn't, but it doesn't hurt, either.  I don't see any need for it in
1.1.2, though.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

[making initializer functions static]
> Why is this necessary if we use Jason's patch?

Because of the example that triggered the whole thread: You use two
shared libraries which both have the same global function. Ian Taylor
tells me that this is legal and standard use, despite its violating
the odr. People do such things with shared libraries.

Now, you create global objects in each shared library, which are keyed
to the global function. The dynamic linker will then initialize one
object twice, and the other not-at-all.

If we think this is legal use, we should fix the problem.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902172339.AAA01000@mira.isdn.cs.tu-berlin.de >you write:
  > [making initializer functions static]
  > > Why is this necessary if we use Jason's patch?
  > 
  > Because of the example that triggered the whole thread: You use two
  > shared libraries which both have the same global function. Ian Taylor
  > tells me that this is legal and standard use, despite its violating
  > the odr. People do such things with shared libraries.
  > 
  > Now, you create global objects in each shared library, which are keyed
  > to the global function. The dynamic linker will then initialize one
  > object twice, and the other not-at-all.
  > 
  > If we think this is legal use, we should fix the problem.
But doesn't Jason's patch avoid this problem by munging the name?


jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> But doesn't Jason's patch avoid this problem by munging the name?

Maybe I haven't seen Jason's patch, then. Current g++ only munges the
name of the source file, if that is used to provide uniqueness. If we
have a global symbol, we are dead sure that it is already unique, and
requires no munging.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> But doesn't Jason's patch avoid this problem by munging the name?

Maybe I haven't seen Jason's patch, then. Current g++ only munges the
name of the source file, if that is used to provide uniqueness. If we
have a global symbol, we are dead sure that it is already unique, and
requires no munging.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902172339.AAA01000@mira.isdn.cs.tu-berlin.de >you write:
  > [making initializer functions static]
  > > Why is this necessary if we use Jason's patch?
  > 
  > Because of the example that triggered the whole thread: You use two
  > shared libraries which both have the same global function. Ian Taylor
  > tells me that this is legal and standard use, despite its violating
  > the odr. People do such things with shared libraries.
  > 
  > Now, you create global objects in each shared library, which are keyed
  > to the global function. The dynamic linker will then initialize one
  > object twice, and the other not-at-all.
  > 
  > If we think this is legal use, we should fix the problem.
But doesn't Jason's patch avoid this problem by munging the name?


jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

[making initializer functions static]
> Why is this necessary if we use Jason's patch?

Because of the example that triggered the whole thread: You use two
shared libraries which both have the same global function. Ian Taylor
tells me that this is legal and standard use, despite its violating
the odr. People do such things with shared libraries.

Now, you create global objects in each shared library, which are keyed
to the global function. The dynamic linker will then initialize one
object twice, and the other not-at-all.

If we think this is legal use, we should fix the problem.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10D8I7-00038sC@ocean.lucon.org >you write:
  > > 
  > > >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
  > > 
  > >  > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
  > >  > perfect, but it is good enough IMHO.
  > > 
  > >  > So, what changes do I need to pull into egcs-1.1.2?
  > > 
  > > Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
  > > 
  > >         * tree.c (append_random_chars): New fn.
  > >         (get_file_function_name_long): Use it.
  > > 
  > > It will need to be massaged a bit because 1.1.x doesn't have the change f
  > or
  > > get_file_function_name_long, but that's not important.
  > > 
  > > Jason
  > 
  > No matter what you use, please make sure ctors/dtors are local on
  > ELF.
Why is this necessary if we use Jason's patch?

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
>  > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
>  > perfect, but it is good enough IMHO.
> 
>  > So, what changes do I need to pull into egcs-1.1.2?
> 
> Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
> 
>         * tree.c (append_random_chars): New fn.
>         (get_file_function_name_long): Use it.
> 
> It will need to be massaged a bit because 1.1.x doesn't have the change for
> get_file_function_name_long, but that's not important.
> 
> Jason

No matter what you use, please make sure ctors/dtors are local on
ELF.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < u9iud1iiwm.fsf@yorick.cygnus.com >you write:
  > Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
  > 
  >         * tree.c (append_random_chars): New fn.
  >         (get_file_function_name_long): Use it.
  > 
  > It will need to be massaged a bit because 1.1.x doesn't have the change for
  > get_file_function_name_long, but that's not important.
Right.  I went back and extracted the get_file_function_name_long change and
installed it along with the change referenced above.

I also fixed up aoutos.h and installed the cp/decl2.c patch as has been
discussed.

This should fix the multiple definition problems.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < u9iud1iiwm.fsf@yorick.cygnus.com >you write:
  > Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>
  > 
  >         * tree.c (append_random_chars): New fn.
  >         (get_file_function_name_long): Use it.
  > 
  > It will need to be massaged a bit because 1.1.x doesn't have the change for
  > get_file_function_name_long, but that's not important.
Right.  I went back and extracted the get_file_function_name_long change and
installed it along with the change referenced above.

I also fixed up aoutos.h and installed the cp/decl2.c patch as has been
discussed.

This should fix the multiple definition problems.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 > timestamp ^ pid seems quite reasonable to me too.  It's not 100%
 > perfect, but it is good enough IMHO.

 > So, what changes do I need to pull into egcs-1.1.2?

Wed Oct 28 22:58:35 1998  Jason Merrill  <jason@yorick.cygnus.com>

        * tree.c (append_random_chars): New fn.
        (get_file_function_name_long): Use it.

It will need to be massaged a bit because 1.1.x doesn't have the change for
get_file_function_name_long, but that's not important.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < u9ww1ii3mw.fsf@yorick.cygnus.com >you write:
  > The current code uses timestamp ^ pid directly, without going through the
  > random number generator.  The code was lifted from mkstemp in libiberty.
  > 
  > Really, this seems entirely adequate to me.  The number of translation
  > units that actually rely on this is small; witness how long it took to fix
  > this problem in the first place.
timestamp ^ pid seems quite reasonable to me too.  It's not 100% perfect, but
it is good enough IMHO.

So, what changes do I need to pull into egcs-1.1.2?

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> Mark Mitchell <mark@markmitchell.com> writes:

>>>>> "H" == H J Lu <hjl@lucon.org> writes:
 H> I see. How about removing hostname and domainname?

 H> For anonymouse namspace, they are global. I don't think random
 H> bits alone are any better than timestamp. How about timestamp +
 H> random bits?

 > Sure, that's fine.  But, why bother?  Random bits are very, very good.
 > Anything is else is an unnecessary complication.  Using more random
 > bits is easier that throwing in any other attempted uniquifications.

 > We just need a pile of bits.  If I were you, I'd seed the random
 > number generator with a hash of timestamp + pid + ip address, and call
 > it good enough.

The current code uses timestamp ^ pid directly, without going through the
random number generator.  The code was lifted from mkstemp in libiberty.

Really, this seems entirely adequate to me.  The number of translation
units that actually rely on this is small; witness how long it took to fix
this problem in the first place.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> >>>>> "H" == H J Lu <hjl@lucon.org> writes:
> 
>     H> Here is my proposal. main () in toplev.c calls unique_string ()
>     H> to initialize a static variable in tree.c:
> 
> In my opinion, this is not a good proposal.  In another life, I work
> on issues of computer security, and silently putting things that might
> reveal the hostname where the program is compiled in .o files is not
> at all a good thing.

I see. How about removing hostname and domainname?

> 
> If we can make the functions static, the problem goes away, right?  If
> not, then sufficiently many random bits is just fine.  I would guess
> that 2048 would be more than enough for quite some time to come.
> 

For anonymouse namspace, they are global. I don't think random bits
alone are any better than timestamp. How about timestamp + random bits?


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    H> Here is my proposal. main () in toplev.c calls unique_string ()
    H> to initialize a static variable in tree.c:

In my opinion, this is not a good proposal.  In another life, I work
on issues of computer security, and silently putting things that might
reveal the hostname where the program is compiled in .o files is not
at all a good thing.

If we can make the functions static, the problem goes away, right?  If
not, then sufficiently many random bits is just fine.  I would guess
that 2048 would be more than enough for quite some time to come.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
> 
>   In message < m10Boh4-000392C@ocean.lucon.org >you write:
>   > It is a very hard problem. It may not have solutons for all platforms.
>   > But it doesn't mean we should not fix those we can fix.
> But it also doesn't mean we take the stance of fixing linux and ignoring
> everything else.
> 

Here is my proposal. main () in toplev.c calls unique_string () to
initialize a static variable in tree.c:

static char *file_function_name_base;

with

	file_function_name_base = unique_string ();

We also add a counter in tree.c:

static int file_function_name_counter;

get_file_function_name in tree.c will create a file funtcion name with

	file_function_name = file_function_name_base
			     + main_input_filename
			     + file_function_name_counter;

This way we can say with quite confidence that file_function_name will
be unique across all machines in the world for a given OS on a given
arch if they are configured properly. Of course, it may not work for
all OSes. But it should cover most if not all Unix-alike systems.

> Furthermore, this is an ABI/API change, we want to be very careful making
> such changes.
> 

I am not sure if the ABI/API change caused by making global ctors/dtors
static is visible to user. At least, it should be safe on ELF systems.


-- 
H.J. Lu (hjl@gnu.org)
---
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#if defined HAVE_SYS_UTSNAME_H && defined HAVE_UNAME
#include <sys/utsname.h>
#endif

#if defined HAVE_TIME_H && defined HAVE_STRFTIME \
    && defined HAVE_GMTIME && defined HAVE_TIME
#include <time.h>
#endif

#define xmalloc	malloc

#define is_valid_symbol_char(c) \
  ((c) == '_' || (c) == '.' || ((c) >= '0' && (c) <= '9') \
   || ((c) >= 'a' && (c) <= 'z') || ((c) >= 'A' && (c) <= 'Z'))

char *
unique_string ()
{
  char *domainname = NULL;
  char *hostname = NULL;
  char *sysname = NULL;
  char *release = NULL;
  char *version = NULL;
  char *machine = NULL;
  char current_time [] = "yyyymmddhhmmss";
  long pid = getpid ();
  char *unique_name;
  int len;

#ifdef HAVE_GETDOMAINNAME
  {
    len = 0;
    do
      {
	len += 128;
	domainname = (char *) alloca (len);
	if (getdomainname (domainname, len) == 0)
	  break;
	else
	  domainname = NULL;
      }
    while (len < 512);
  }
#endif

#ifdef HAVE_GETHOSTNAME
  {
    len = 0;
    do
      {
	len += 128;
	hostname = (char *) alloca (len);
	if (gethostname (hostname, len) == 0)
	  break;
	else
	  hostname = NULL;
      }
    while (len < 512);
  }
#endif

#if defined HAVE_UNAME && defined HAVE_SYS_UTSNAME_H
  {
    struct utsname utsname;

    if (uname (&utsname) == 0)
      {
#ifdef HAVE_DOMAINNAME_IN_UTSNAME
        if (!domainname)
	  domainname = utsname.domainname;
#endif
#ifdef HAVE_NODENAME_IN_UTSNAME
        if (!hostname)
	  hostname = utsname.nodename;
#endif
#ifdef HAVE_SYSNAME_IN_UTSNAME
	sysname = utsname.sysname;
#endif
#ifdef HAVE_RELEASE_IN_UTSNAME
	release = utsname.release;
#endif
#ifdef HAVE_VERSION_IN_UTSNAME
	version = utsname.version;
#endif
#ifdef HAVE_MACHINE_IN_UTSNAME
	machine = utsname.machine;
#endif
      }
  }
#endif

  if (!domainname || *domainname == '\0')
    domainname = "localdomain";

  if (!hostname || *hostname == '\0')
    hostname = "localhost";

  if (!sysname || *sysname == '\0')
    sysname = "UnknownOS";

  if (!release || *release == '\0')
    release = "UnknownRelease";

  if (!version || *version == '\0')
    version = "UnknownVersion";

  if (!machine || *machine == '\0')
    machine = "UnknownMachine";

#if defined HAVE_STRFTIME && defined HAVE_GMTIME && defined HAVE_TIME
  {
    time_t t;
    
    t = time (NULL);
    if (strftime (current_time, sizeof (current_time),
    		  "%Y%m%d%H%M%S", gmtime (&t)) == 0)
      strcpy (current_time, "yyyymmddhhmmss");
  }
#endif

  {
    char *dot = strchr (hostname, '.');

    if (!dot || strchr (++dot, '.') == NULL)
      {
        /* There are no 2 dots in hostname. We need to append the
	   domainname. */
	len = 1 + strlen (hostname) + 1 + strlen (domainname)
	      + strlen (sysname) + strlen (release) + strlen (version)
	      + strlen (machine) + sizeof (current_time) + 8;

	unique_name = xmalloc (len);

        sprintf (unique_name, "_%s.%s%s%s%s%s%s%.8x",
		 hostname, domainname, sysname, release, version,
		 machine, current_time, pid);
      }
    else
      {
	len = 1 + strlen (hostname)
	      + strlen (sysname) + strlen (release) + strlen (version)
	      + strlen (machine) + sizeof (current_time) + 8;

	unique_name = xmalloc (len);

        sprintf (unique_name, "_%s%s%s%s%s%s%.8x",
		 hostname, sysname, release, version,
		 machine, current_time, pid);
      }
  }

  {
    int i;

    for (i = 1; i < len - 1 - sizeof (current_time) - 8; i++)
      {
        if (!is_valid_symbol_char (unique_name [i]))
	  unique_name [i] = '_';
      }
  }
  return unique_name;
}

main ()
{
  printf ("%s\n", unique_string ());
}

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10Boh4-000392C@ocean.lucon.org >you write:
  > It is a very hard problem. It may not have solutons for all platforms.
  > But it doesn't mean we should not fix those we can fix.
But it also doesn't mean we take the stance of fixing linux and ignoring
everything else.

Furthermore, this is an ABI/API change, we want to be very careful making
such changes.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
>   In message < m10BoHn-000392C@ocean.lucon.org >you write:
>   > > 
>   > > > So what is the consensus solution for egcs-1.1.2?  I haven't seen anyth
>   > ing
>   > > > concrete yet.
>   > > 
>   > > I think the minimal solution is to make initializer symbols static on
>   > > ELF systems. HJ has a patch, although I haven't reviewed it to see
>   > > whether it does what it promises to do.
>   > 
>   > I am only interested in Linux. If we really cannot fix the problem for
>   > all platforms, it is ok with me as long as Linux is ok :-(.
> That may be your only concern, but this project is not just a linux compiler.
> We have to think about broader scopes than just linux.
> 

It is a very hard problem. It may not have solutons for all platforms.
But it doesn't mean we should not fix those we can fix.


H.J.

egcs and linux

[Steinar Bang]

>>>>> Jeffrey A Law <law@hurl.cygnus.com>:

> That may be your only concern, but this project is not just a linux
> compiler.  We have to think about broader scopes than just linux.

Linux is a _very_ important platform for egcs.  Egcs _really_ should
be able to work on linux without any patches.  

Today 1.1.1 doesn't work properly on linux without H.J.'s patches.

IMHO 1.1.2 should not be released at all, before it will work on linux
without patches.

Re: egcs and linux

[Marc Espie]

In article < wh1zjtgnwy.fsf@viffer.oslo.metis.no > you write:
>>>>>> Jeffrey A Law <law@hurl.cygnus.com>:

>> That may be your only concern, but this project is not just a linux
>> compiler.  We have to think about broader scopes than just linux.

>Linux is a _very_ important platform for egcs.  Egcs _really_ should
>be able to work on linux without any patches.  

So get clean patches *in* that won't annoy other architectures.
I'm currently working to get egcs to work with almost no patches on OpenBSD.
Why almost ? because there are philosophical differences, and all the world
is not OpenBSD. Nor Linux. Nor Hurd. I'm always pushing to give my point
of view, especially where I think it matters in the general idea, but I don't
really expect all the sillyness OpenBSD would like to impose on egcs to 
matter, in the end.

>Today 1.1.1 doesn't work properly on linux without H.J.'s patches.

>IMHO 1.1.2 should not be released at all, before it will work on linux
>without patches.

Your opinion doesn't matter. Clean code does.

What's important is to understand differences, and cater for them the 
way they're needed. The day the egcs project starts moving to accommodate
the linux crowd to the detriment of other architectures is the day *I'm*
dropping it.

Besides, who cares about being able to work out of the box without patches ?
This is a technical area. People who know what the patches fix will know how
where to get them, or what to patch themselves. Heck, I've asked enough silly
questions on this ml recently to be dead sure I was doing things the right
way...

Re: egcs and linux

[Steinar Bang]

>>>>> Marc Espie <espie@quatramaran.ens.fr>:

> In article < wh1zjtgnwy.fsf@viffer.oslo.metis.no > you write:

>> IMHO 1.1.2 should not be released at all, before it will work on linux
>> without patches.

> Your opinion doesn't matter. Clean code does.

How can the egcs code possibly be clean if egcs doesn't run correctly
on one of its most important platforms?

Boggles the mind!

Is it possible to put the HJ patches within linux-specific ifdefs?

Re: egcs and linux

[Jeffrey A Law]

  In message < whogmxdn6i.fsf@viffer.oslo.metis.no >you write:
  > Is it possible to put the HJ patches within linux-specific ifdefs?
No.  Absolutely not.

jeff

Re: egcs and linux

[Jeffrey A Law]

  In message < whogmxdn6i.fsf@viffer.oslo.metis.no >you write:
  > Is it possible to put the HJ patches within linux-specific ifdefs?
No.  Absolutely not.

jeff

Re: egcs and linux

[Steinar Bang]

>>>>> Marc Espie <espie@quatramaran.ens.fr>:

> In article < wh1zjtgnwy.fsf@viffer.oslo.metis.no > you write:

>> IMHO 1.1.2 should not be released at all, before it will work on linux
>> without patches.

> Your opinion doesn't matter. Clean code does.

How can the egcs code possibly be clean if egcs doesn't run correctly
on one of its most important platforms?

Boggles the mind!

Is it possible to put the HJ patches within linux-specific ifdefs?

Re: egcs and linux

[Marc Espie]

In article < wh1zjtgnwy.fsf@viffer.oslo.metis.no > you write:
>>>>>> Jeffrey A Law <law@hurl.cygnus.com>:

>> That may be your only concern, but this project is not just a linux
>> compiler.  We have to think about broader scopes than just linux.

>Linux is a _very_ important platform for egcs.  Egcs _really_ should
>be able to work on linux without any patches.  

So get clean patches *in* that won't annoy other architectures.
I'm currently working to get egcs to work with almost no patches on OpenBSD.
Why almost ? because there are philosophical differences, and all the world
is not OpenBSD. Nor Linux. Nor Hurd. I'm always pushing to give my point
of view, especially where I think it matters in the general idea, but I don't
really expect all the sillyness OpenBSD would like to impose on egcs to 
matter, in the end.

>Today 1.1.1 doesn't work properly on linux without H.J.'s patches.

>IMHO 1.1.2 should not be released at all, before it will work on linux
>without patches.

Your opinion doesn't matter. Clean code does.

What's important is to understand differences, and cater for them the 
way they're needed. The day the egcs project starts moving to accommodate
the linux crowd to the detriment of other architectures is the day *I'm*
dropping it.

Besides, who cares about being able to work out of the box without patches ?
This is a technical area. People who know what the patches fix will know how
where to get them, or what to patch themselves. Heck, I've asked enough silly
questions on this ml recently to be dead sure I was doing things the right
way...

Re: egcs and linux

[Jeffrey A Law]

  In message < wh1zjtgnwy.fsf@viffer.oslo.metis.no >you write:
  > IMHO 1.1.2 should not be released at all, before it will work on linux
  > without patches.
Our opinions differ then.

There are some patches HJ is distributing that certainly will not be in 
egcs-1.1.2.

Jeff

Re: egcs and linux

[Steinar Bang]

>>>>> Jeffrey A Law <law@hurl.cygnus.com>:

>   In message < wh1zjtgnwy.fsf@viffer.oslo.metis.no >you write:
>> IMHO 1.1.2 should not be released at all, before it will work on linux
>> without patches.

> Our opinions differ then.

> There are some patches HJ is distributing that certainly will not be in 
> egcs-1.1.2.

Will the fix for the bug triggered by
	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz
be in? (unpack and do a make using GNU make on a linux installation
with egcs 1.1.1, and get a linker error attempting to build a shared
library on vanilla egcs 1.1.1)

Re: egcs and linux

[Jeffrey A Law]

  In message < whemntdl8m.fsf@viffer.oslo.metis.no >you write:
  > >>>>> Jeffrey A Law <law@hurl.cygnus.com>:
  > 
  > >   In message < wh1zjtgnwy.fsf@viffer.oslo.metis.no >you write:
  > >> IMHO 1.1.2 should not be released at all, before it will work on linux
  > >> without patches.
  > 
  > > Our opinions differ then.
  > 
  > > There are some patches HJ is distributing that certainly will not be in 
  > > egcs-1.1.2.
  > 
  > Will the fix for the bug triggered by
  > 	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz
  > be in? (unpack and do a make using GNU make on a linux installation
  > with egcs 1.1.1, and get a linker error attempting to build a shared
  > library on vanilla egcs 1.1.1)
I don't know since I don't know what change fixes that problem.  

jeff

Re: egcs and linux

[Jeffrey A Law]

  In message < whemntdl8m.fsf@viffer.oslo.metis.no >you write:
  > >>>>> Jeffrey A Law <law@hurl.cygnus.com>:
  > 
  > >   In message < wh1zjtgnwy.fsf@viffer.oslo.metis.no >you write:
  > >> IMHO 1.1.2 should not be released at all, before it will work on linux
  > >> without patches.
  > 
  > > Our opinions differ then.
  > 
  > > There are some patches HJ is distributing that certainly will not be in 
  > > egcs-1.1.2.
  > 
  > Will the fix for the bug triggered by
  > 	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz
  > be in? (unpack and do a make using GNU make on a linux installation
  > with egcs 1.1.1, and get a linker error attempting to build a shared
  > library on vanilla egcs 1.1.1)
I don't know since I don't know what change fixes that problem.  

jeff

Re: egcs and linux

[Steinar Bang]

>>>>> Jeffrey A Law <law@hurl.cygnus.com>:

>   In message < wh1zjtgnwy.fsf@viffer.oslo.metis.no >you write:
>> IMHO 1.1.2 should not be released at all, before it will work on linux
>> without patches.

> Our opinions differ then.

> There are some patches HJ is distributing that certainly will not be in 
> egcs-1.1.2.

Will the fix for the bug triggered by
	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz
be in? (unpack and do a make using GNU make on a linux installation
with egcs 1.1.1, and get a linker error attempting to build a shared
library on vanilla egcs 1.1.1)

Re: egcs and linux

[Jeffrey A Law]

  In message < wh1zjtgnwy.fsf@viffer.oslo.metis.no >you write:
  > IMHO 1.1.2 should not be released at all, before it will work on linux
  > without patches.
Our opinions differ then.

There are some patches HJ is distributing that certainly will not be in 
egcs-1.1.2.

Jeff

Re: egcs and linux

[Scott McDermott]

On Sun 14/02 13:39 +0100, Steinar Bang wrote:
> > That may be your only concern, but this project is not just a linux
> > compiler.  We have to think about broader scopes than just linux.
> 
> Linux is a _very_ important platform for egcs.  Egcs _really_ should
> be able to work on linux without any patches.  
> 
> Today 1.1.1 doesn't work properly on linux without H.J.'s patches.

I've been able to compile egcs-1.1.1 on Linux (2.0, glibc same) without
difficulty, and compiled dozens of programs that have worked without
error.

Specifically, what are HJL's patches for, and when would they be
`necessary?'

-- 
Scott

Re: egcs and linux

[Steinar Bang]

>>>>> Scott McDermott <vaxerdec@frontiernet.net>:

> On Sun 14/02 13:39 +0100, Steinar Bang wrote:

>> Today 1.1.1 doesn't work properly on linux without H.J.'s patches.

> I've been able to compile egcs-1.1.1 on Linux (2.0, glibc same)
> without difficulty, and compiled dozens of programs that have worked
> without error.

Try getting 
	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz
cd to the egcslinkso directory, unpack and do a make.  If the shared
library in the directory builds, then I would very much like to know
your exact configuration of kernel and libc and everything relevant.

> Specifically, what are HJL's patches for, and when would they be
> `necessary?'

Well,... I can only speak for myself: when I encounter a bug in the
compiler that won't let me build my application.

Re: egcs and linux

[Steinar Bang]

>>>>> Scott McDermott <vaxerdec@frontiernet.net>:

> On Sun 14/02 13:39 +0100, Steinar Bang wrote:

>> Today 1.1.1 doesn't work properly on linux without H.J.'s patches.

> I've been able to compile egcs-1.1.1 on Linux (2.0, glibc same)
> without difficulty, and compiled dozens of programs that have worked
> without error.

Try getting 
	http://www.metis.no/private/sb/misc/egcslinkso.tar.gz
cd to the egcslinkso directory, unpack and do a make.  If the shared
library in the directory builds, then I would very much like to know
your exact configuration of kernel and libc and everything relevant.

> Specifically, what are HJL's patches for, and when would they be
> `necessary?'

Well,... I can only speak for myself: when I encounter a bug in the
compiler that won't let me build my application.

Re: egcs and linux

[Scott McDermott]

On Sun 14/02 13:39 +0100, Steinar Bang wrote:
> > That may be your only concern, but this project is not just a linux
> > compiler.  We have to think about broader scopes than just linux.
> 
> Linux is a _very_ important platform for egcs.  Egcs _really_ should
> be able to work on linux without any patches.  
> 
> Today 1.1.1 doesn't work properly on linux without H.J.'s patches.

I've been able to compile egcs-1.1.1 on Linux (2.0, glibc same) without
difficulty, and compiled dozens of programs that have worked without
error.

Specifically, what are HJL's patches for, and when would they be
`necessary?'

-- 
Scott

Re: egcs and linux

[Joe Buck]

> Linux is a _very_ important platform for egcs.  Egcs _really_ should
> be able to work on linux without any patches.  

Yes, ideally we should try to achieve this.

> Today 1.1.1 doesn't work properly on linux without H.J.'s patches.

Statements like this aren't that useful.  The real story is that there
are problems caused by the interaction of specific versions of libc and
libstdc++ that show up in specific circumstances.  HJ would get less
resistance to his patches if clearly described test cases were available
and added to the testsuite.  Or people could come up with cleaner patches
to solve the problems.

The problems would then show up as failures when people ran the tests,
and we wouldn't be surprised by them after the release.

> IMHO 1.1.2 should not be released at all, before it will work on linux
> without patches.

You can help achieve this by submitting test cases that cause the existing
snapshot to fail and describing the failures.

Re: egcs and linux

[H.J. Lu]

> > Today 1.1.1 doesn't work properly on linux without H.J.'s patches.
> 
> Statements like this aren't that useful.  The real story is that there
> are problems caused by the interaction of specific versions of libc and
> libstdc++ that show up in specific circumstances.  HJ would get less
> resistance to his patches if clearly described test cases were available
> and added to the testsuite.  Or people could come up with cleaner patches
> to solve the problems.
> 
> The problems would then show up as failures when people ran the tests,
> and we wouldn't be surprised by them after the release.
> 
> > IMHO 1.1.2 should not be released at all, before it will work on linux
> > without patches.
> 
> You can help achieve this by submitting test cases that cause the existing
> snapshot to fail and describing the failures.
> 

Please remember egcs is used as a native compiler on Linux.
Many Linux testcases are quite complicated. As you have noted
that those bugs only show up in specific circumstances. A testcase
may mean

1. A Linux machine with specific packages installed.
2. A Makefile and several source files.

How can such a testcase be included in the egcs testsuite?

I have no problems with making Linux versions of egcs. I am
used to it by now :-). Those affected are Linux users and
egcs' reputation on Linux.


-- 
H.J. Lu (hjl@gnu.org)

Re: egcs and linux

[Joe Buck]

HJ writes:
> I have no problems with making Linux versions of egcs. I am
> used to it by now :-).

But I do have a problem with it.  (That is, I do have a problem with the
notion that the version delivered by the egcs team won't work on Linux,
and that Linux users will have to download a separate HJ version to have
a working compiler).  Since you provide binary releases and encourage
people to use them, it's a step away from the notion of free software
for the community to share and improve.  It conveys the idea that only
wizards like HJ should attempt to compile the compiler.

Re: egcs and linux

[H.J. Lu]

> 
> HJ writes:
> > I have no problems with making Linux versions of egcs. I am
> > used to it by now :-).
> 
> But I do have a problem with it.  (That is, I do have a problem with the
> notion that the version delivered by the egcs team won't work on Linux,
> and that Linux users will have to download a separate HJ version to have
> a working compiler).  Since you provide binary releases and encourage
> people to use them, it's a step away from the notion of free software

I encourage people to apply my patch before using egcs on Linux. I
don't want to make binaries. But I am asked to do so.

> for the community to share and improve.  It conveys the idea that only
> wizards like HJ should attempt to compile the compiler.
> 

I don't want to make Linux specific egcs. But it seems to me that I
am the only one who will spend time and effort to make egcs work right
under Linux. To do that, you do need to know the details about C/C++
libraries and how they work with egcs.

BTW, Linux/ARM and Linux/MIPS need a compiler/linker/assembler. I do
support them in my Linux releases of egcs and binutils. I will be more
than happy to see egcs 1.1.2 support them out of box. Will that be
possible? I really doubt it. I don't think egcs has that kind of
commitments to Linux and I don't expect it to.


-- 
H.J. Lu (hjl@gnu.org)

Re: egcs and linux

[Scott Bambrough]

"H.J. Lu" wrote:
> 
> BTW, Linux/ARM and Linux/MIPS need a compiler/linker/assembler. I do
> support them in my Linux releases of egcs and binutils. I will be more
> than happy to see egcs 1.1.2 support them out of box. Will that be
> possible? I really doubt it. I don't think egcs has that kind of
> commitments to Linux and I don't expect it to.

ARM ELF changes for Linux are being worked into GAS2 ATM.  Phil Blundell, Pat
Beirne and I have patches for EGCS that need to be integrated.  I actually
just moved Corel's changes into the code from the CVS tree today.  Anyone want
to help us get the ARM changes  merged?

Scott

Re: egcs and linux

[Scott Bambrough]

"H.J. Lu" wrote:
> 
> BTW, Linux/ARM and Linux/MIPS need a compiler/linker/assembler. I do
> support them in my Linux releases of egcs and binutils. I will be more
> than happy to see egcs 1.1.2 support them out of box. Will that be
> possible? I really doubt it. I don't think egcs has that kind of
> commitments to Linux and I don't expect it to.

ARM ELF changes for Linux are being worked into GAS2 ATM.  Phil Blundell, Pat
Beirne and I have patches for EGCS that need to be integrated.  I actually
just moved Corel's changes into the code from the CVS tree today.  Anyone want
to help us get the ARM changes  merged?

Scott

Re: egcs and linux

[H.J. Lu]

> 
> HJ writes:
> > I have no problems with making Linux versions of egcs. I am
> > used to it by now :-).
> 
> But I do have a problem with it.  (That is, I do have a problem with the
> notion that the version delivered by the egcs team won't work on Linux,
> and that Linux users will have to download a separate HJ version to have
> a working compiler).  Since you provide binary releases and encourage
> people to use them, it's a step away from the notion of free software

I encourage people to apply my patch before using egcs on Linux. I
don't want to make binaries. But I am asked to do so.

> for the community to share and improve.  It conveys the idea that only
> wizards like HJ should attempt to compile the compiler.
> 

I don't want to make Linux specific egcs. But it seems to me that I
am the only one who will spend time and effort to make egcs work right
under Linux. To do that, you do need to know the details about C/C++
libraries and how they work with egcs.

BTW, Linux/ARM and Linux/MIPS need a compiler/linker/assembler. I do
support them in my Linux releases of egcs and binutils. I will be more
than happy to see egcs 1.1.2 support them out of box. Will that be
possible? I really doubt it. I don't think egcs has that kind of
commitments to Linux and I don't expect it to.


-- 
H.J. Lu (hjl@gnu.org)

Re: egcs and linux

[Horst von Brand]

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

Joe Buck <jbuck@Synopsys.COM> said:
> HJ writes:
> > I have no problems with making Linux versions of egcs. I am
> > used to it by now :-).

> But I do have a problem with it.  (That is, I do have a problem with the
> notion that the version delivered by the egcs team won't work on Linux,
> and that Linux users will have to download a separate HJ version to have
> a working compiler).  Since you provide binary releases and encourage
> people to use them, it's a step away from the notion of free software
> for the community to share and improve.  It conveys the idea that only
> wizards like HJ should attempt to compile the compiler.

Could somebody tell me (in private) what the problem is? I'm using egcs
(mostly snapshots, latest is 19990214) for most all my compiling needs
(except for linux-2.0 kernels) here for almost a year now, and see no
problems. I've been away lately, so I haven't followed this particular
thread.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile                               +56 32 672616

Re: egcs and linux

[Horst von Brand]

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

Joe Buck <jbuck@Synopsys.COM> said:
> HJ writes:
> > I have no problems with making Linux versions of egcs. I am
> > used to it by now :-).

> But I do have a problem with it.  (That is, I do have a problem with the
> notion that the version delivered by the egcs team won't work on Linux,
> and that Linux users will have to download a separate HJ version to have
> a working compiler).  Since you provide binary releases and encourage
> people to use them, it's a step away from the notion of free software
> for the community to share and improve.  It conveys the idea that only
> wizards like HJ should attempt to compile the compiler.

Could somebody tell me (in private) what the problem is? I'm using egcs
(mostly snapshots, latest is 19990214) for most all my compiling needs
(except for linux-2.0 kernels) here for almost a year now, and see no
problems. I've been away lately, so I haven't followed this particular
thread.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile                               +56 32 672616

Re: egcs and linux

[Joe Buck]

HJ writes:
> I have no problems with making Linux versions of egcs. I am
> used to it by now :-).

But I do have a problem with it.  (That is, I do have a problem with the
notion that the version delivered by the egcs team won't work on Linux,
and that Linux users will have to download a separate HJ version to have
a working compiler).  Since you provide binary releases and encourage
people to use them, it's a step away from the notion of free software
for the community to share and improve.  It conveys the idea that only
wizards like HJ should attempt to compile the compiler.

Re: egcs and linux

[Joe Buck]

HJ writes:

> Please remember egcs is used as a native compiler on Linux.
> Many Linux testcases are quite complicated. As you have noted
> that those bugs only show up in specific circumstances. A testcase
> may mean
> 
> 1. A Linux machine with specific packages installed.
> 2. A Makefile and several source files.
> 
> How can such a testcase be included in the egcs testsuite?

#1 can't be included; #2, in theory, could be.  Since the real problem
is often glibc/libstdc++ interaction, or issues with dynamic linking,
I wouldn't be surprised if some of these failures show up also on the
Hurd (e.g. in the Debian/HURD system people are putting together) or
even with dynamic linking on other ELF systems.  This means you wouldn't
want to include #1 even if you wanted to, you'd just describe cases
where you expect failures.

We can't currently handle Makefiles in the test suite, but perhaps we can
just have a separate set of tests for these problems, maybe in
/pub/egcs/contrib or something, which would be invoked by simply typing
"make" (which would then build a tree).  There's been work on
multiple-file tests, but I haven't looked at it.

I would then support you in saying that egcs 1.1.2 must run those tests
correctly (you could describe the problematic systems or how to duplicate
failures).

Re: egcs and linux

[H.J. Lu]

> > Many Linux testcases are quite complicated. As you have noted
> > that those bugs only show up in specific circumstances. A testcase
> > may mean
> > 
> > 1. A Linux machine with specific packages installed.
> > 2. A Makefile and several source files.
> > 
> > How can such a testcase be included in the egcs testsuite?
> 
> #1 can't be included; #2, in theory, could be.  Since the real problem
> is often glibc/libstdc++ interaction, or issues with dynamic linking,

Make that glibc/libc5/libstdc++/libg++. Yes, there are some
applications on Linux which uses libg++. groff and netscape are
among them. You may have to be on the cutting edge to see the problem.
That is one reason I usually see the problem first before anyone else.


> I wouldn't be surprised if some of these failures show up also on the
> Hurd (e.g. in the Debian/HURD system people are putting together) or
> even with dynamic linking on other ELF systems.  This means you wouldn't
> want to include #1 even if you wanted to, you'd just describe cases
> where you expect failures.

I doubt a testcase will show the problem without (1). The main reason
other people don't see the problem is (1).

> 
> I would then support you in saying that egcs 1.1.2 must run those tests
> correctly (you could describe the problematic systems or how to duplicate
> failures).
> 
> 

It will be very hard for me to explain problems in words only. If
they are so simple, I won't need to write this message. To really
understand it, you need to know the internals of libc, libstdc++,
and libg++.


-- 
H.J. Lu (hjl@gnu.org)

Re: egcs and linux

[H.J. Lu]

> > Many Linux testcases are quite complicated. As you have noted
> > that those bugs only show up in specific circumstances. A testcase
> > may mean
> > 
> > 1. A Linux machine with specific packages installed.
> > 2. A Makefile and several source files.
> > 
> > How can such a testcase be included in the egcs testsuite?
> 
> #1 can't be included; #2, in theory, could be.  Since the real problem
> is often glibc/libstdc++ interaction, or issues with dynamic linking,

Make that glibc/libc5/libstdc++/libg++. Yes, there are some
applications on Linux which uses libg++. groff and netscape are
among them. You may have to be on the cutting edge to see the problem.
That is one reason I usually see the problem first before anyone else.


> I wouldn't be surprised if some of these failures show up also on the
> Hurd (e.g. in the Debian/HURD system people are putting together) or
> even with dynamic linking on other ELF systems.  This means you wouldn't
> want to include #1 even if you wanted to, you'd just describe cases
> where you expect failures.

I doubt a testcase will show the problem without (1). The main reason
other people don't see the problem is (1).

> 
> I would then support you in saying that egcs 1.1.2 must run those tests
> correctly (you could describe the problematic systems or how to duplicate
> failures).
> 
> 

It will be very hard for me to explain problems in words only. If
they are so simple, I won't need to write this message. To really
understand it, you need to know the internals of libc, libstdc++,
and libg++.


-- 
H.J. Lu (hjl@gnu.org)

Re: egcs and linux

[Joe Buck]

HJ writes:

> Please remember egcs is used as a native compiler on Linux.
> Many Linux testcases are quite complicated. As you have noted
> that those bugs only show up in specific circumstances. A testcase
> may mean
> 
> 1. A Linux machine with specific packages installed.
> 2. A Makefile and several source files.
> 
> How can such a testcase be included in the egcs testsuite?

#1 can't be included; #2, in theory, could be.  Since the real problem
is often glibc/libstdc++ interaction, or issues with dynamic linking,
I wouldn't be surprised if some of these failures show up also on the
Hurd (e.g. in the Debian/HURD system people are putting together) or
even with dynamic linking on other ELF systems.  This means you wouldn't
want to include #1 even if you wanted to, you'd just describe cases
where you expect failures.

We can't currently handle Makefiles in the test suite, but perhaps we can
just have a separate set of tests for these problems, maybe in
/pub/egcs/contrib or something, which would be invoked by simply typing
"make" (which would then build a tree).  There's been work on
multiple-file tests, but I haven't looked at it.

I would then support you in saying that egcs 1.1.2 must run those tests
correctly (you could describe the problematic systems or how to duplicate
failures).

Re: egcs and linux

[H.J. Lu]

> > Today 1.1.1 doesn't work properly on linux without H.J.'s patches.
> 
> Statements like this aren't that useful.  The real story is that there
> are problems caused by the interaction of specific versions of libc and
> libstdc++ that show up in specific circumstances.  HJ would get less
> resistance to his patches if clearly described test cases were available
> and added to the testsuite.  Or people could come up with cleaner patches
> to solve the problems.
> 
> The problems would then show up as failures when people ran the tests,
> and we wouldn't be surprised by them after the release.
> 
> > IMHO 1.1.2 should not be released at all, before it will work on linux
> > without patches.
> 
> You can help achieve this by submitting test cases that cause the existing
> snapshot to fail and describing the failures.
> 

Please remember egcs is used as a native compiler on Linux.
Many Linux testcases are quite complicated. As you have noted
that those bugs only show up in specific circumstances. A testcase
may mean

1. A Linux machine with specific packages installed.
2. A Makefile and several source files.

How can such a testcase be included in the egcs testsuite?

I have no problems with making Linux versions of egcs. I am
used to it by now :-). Those affected are Linux users and
egcs' reputation on Linux.


-- 
H.J. Lu (hjl@gnu.org)

Re: egcs and linux

[Joe Buck]

> Linux is a _very_ important platform for egcs.  Egcs _really_ should
> be able to work on linux without any patches.  

Yes, ideally we should try to achieve this.

> Today 1.1.1 doesn't work properly on linux without H.J.'s patches.

Statements like this aren't that useful.  The real story is that there
are problems caused by the interaction of specific versions of libc and
libstdc++ that show up in specific circumstances.  HJ would get less
resistance to his patches if clearly described test cases were available
and added to the testsuite.  Or people could come up with cleaner patches
to solve the problems.

The problems would then show up as failures when people ran the tests,
and we wouldn't be surprised by them after the release.

> IMHO 1.1.2 should not be released at all, before it will work on linux
> without patches.

You can help achieve this by submitting test cases that cause the existing
snapshot to fail and describing the failures.

egcs and linux

[Steinar Bang]

>>>>> Jeffrey A Law <law@hurl.cygnus.com>:

> That may be your only concern, but this project is not just a linux
> compiler.  We have to think about broader scopes than just linux.

Linux is a _very_ important platform for egcs.  Egcs _really_ should
be able to work on linux without any patches.  

Today 1.1.1 doesn't work properly on linux without H.J.'s patches.

IMHO 1.1.2 should not be released at all, before it will work on linux
without patches.

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m10BoHn-000392C@ocean.lucon.org >you write:
  > > 
  > > > So what is the consensus solution for egcs-1.1.2?  I haven't seen anyth
  > ing
  > > > concrete yet.
  > > 
  > > I think the minimal solution is to make initializer symbols static on
  > > ELF systems. HJ has a patch, although I haven't reviewed it to see
  > > whether it does what it promises to do.
  > 
  > I am only interested in Linux. If we really cannot fix the problem for
  > all platforms, it is ok with me as long as Linux is ok :-(.
That may be your only concern, but this project is not just a linux compiler.
We have to think about broader scopes than just linux.



jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
> > concrete yet.
> 
> I think the minimal solution is to make initializer symbols static on
> ELF systems. HJ has a patch, although I haven't reviewed it to see
> whether it does what it promises to do.

I am only interested in Linux. If we really cannot fix the problem for
all platforms, it is ok with me as long as Linux is ok :-(.

> 
> If somebody can propose a patch that produces significantly
> more-unique symbols than the current code, this should also go into 1.2.
> In this respect, HJ's other patch does not qualify, IMHO.
> 

To me, "significantly more-unique" is still bet on luck. I really
don't like it. I will do something for Linux one way or the other
if I don't like what I see.


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de >you write:
  > I think the minimal solution is to make initializer symbols static on
  > ELF systems. HJ has a patch, although I haven't reviewed it to see
  > whether it does what it promises to do.
I'm not even sure that is correct.

At one time it was possible to build a .o and suck it into your address
space via dynamic loader calls.  And if the .o has static ctors/dtors, the
application is responsible for firing them -- and to do so it must be able
to query the dynamic loader for predictable symbol names.

It's basically the same problem we have with shared libraries for non-ELF
targets.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> At one time it was possible to build a .o and suck it into your address
> space via dynamic loader calls.  And if the .o has static ctors/dtors, the
> application is responsible for firing them -- and to do so it must be able
> to query the dynamic loader for predictable symbol names.

For ELF targets, do you really think this is a widely-used approach?
I'd rather think you'd typically use -ldl and dlopen, which means that
you have to produce a shared library first. If you do that, libdl will
call the constructors even though it doesn't have a symbol name.

If you insist on loading relocatable ELF objects dynamically, you
still can do that: just locate and execute the .init section. No
symbol name needed.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de >you write:
  > For ELF targets, do you really think this is a widely-used approach?
Widely used is not the criteria.  Lots of things are not widely used, but
we still have to support them.

  > If you insist on loading relocatable ELF objects dynamically, you
  > still can do that: just locate and execute the .init section. No
  > symbol name needed.
Do we have a .init section for just the .o?  If so, then ignore this issue.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> Do we have a .init section for just the .o?  If so, then ignore this issue.

No, but we have .ctors. All .ctors sections get concatenated, and
build an array of initializer functions.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> Do we have a .init section for just the .o?  If so, then ignore this issue.

No, but we have .ctors. All .ctors sections get concatenated, and
build an array of initializer functions.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de >you write:
  > For ELF targets, do you really think this is a widely-used approach?
Widely used is not the criteria.  Lots of things are not widely used, but
we still have to support them.

  > If you insist on loading relocatable ELF objects dynamically, you
  > still can do that: just locate and execute the .init section. No
  > symbol name needed.
Do we have a .init section for just the .o?  If so, then ignore this issue.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

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

> For ELF targets, do you really think this is a widely-used approach?
> I'd rather think you'd typically use -ldl and dlopen, which means
> that you have to produce a shared library first. If you do that,
> libdl will call the constructors even though it doesn't have a
> symbol name.

That's what I did and that's where my application croaked.  I
implemented singleton subclasses of an abstract class, and put a
static instance of each class in the compilation unit it was defined
in.

When the .so is loaded the constructor of the singleton is run, and it 
registers itself.

My application croaked on the static instances.  It didn't want more
than one of those in each executable or .so.

For a minimal test case, please see:
	http://egcs.cygnus.com/ml/egcs-bugs/1999-02/msg00469.html

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Steinar Bang]

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

> For ELF targets, do you really think this is a widely-used approach?
> I'd rather think you'd typically use -ldl and dlopen, which means
> that you have to produce a shared library first. If you do that,
> libdl will call the constructors even though it doesn't have a
> symbol name.

That's what I did and that's where my application croaked.  I
implemented singleton subclasses of an abstract class, and put a
static instance of each class in the compilation unit it was defined
in.

When the .so is loaded the constructor of the singleton is run, and it 
registers itself.

My application croaked on the static instances.  It didn't want more
than one of those in each executable or .so.

For a minimal test case, please see:
	http://egcs.cygnus.com/ml/egcs-bugs/1999-02/msg00469.html

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de >you write:
 >> For ELF targets, do you really think this is a widely-used approach?

 > Widely used is not the criteria.  Lots of things are not widely used, but
 > we still have to support them.

We have never supported running ctors for a single .o, and I don't see any
reason to start.  I've never heard of loading a single .o dynamically
without linking it into a shared object.

 >> If you insist on loading relocatable ELF objects dynamically, you
 >> still can do that: just locate and execute the .init section. No
 >> symbol name needed.

 > Do we have a .init section for just the .o?  If so, then ignore this issue.

We have an .init section; we don't have the _init function if we don't link
against crt[in].o.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Joe Buck]

> We have never supported running ctors for a single .o, and I don't see any
> reason to start.  I've never heard of loading a single .o dynamically
> without linking it into a shared object.

Really?  You don't remember ld -A on old BSD (or, to reveal my age, Unix
version 7) systems?  It predates the existence of shared libraries on
Unix.  That's how I implemented incremental linking in Ptolemy on SunOS 4.
It required running a ctor for a single .o.

(Yes, -ldl is more flexible).

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Joe Buck]

> We have never supported running ctors for a single .o, and I don't see any
> reason to start.  I've never heard of loading a single .o dynamically
> without linking it into a shared object.

Really?  You don't remember ld -A on old BSD (or, to reveal my age, Unix
version 7) systems?  It predates the existence of shared libraries on
Unix.  That's how I implemented incremental linking in Ptolemy on SunOS 4.
It required running a ctor for a single .o.

(Yes, -ldl is more flexible).

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < u9yalyi3t6.fsf@yorick.cygnus.com >you write:
  > We have never supported running ctors for a single .o, and I don't see any
  > reason to start.  I've never heard of loading a single .o dynamically
  > without linking it into a shared object.
I was doing this in the early 90s.  Two schemes, one involved sucking
in the .o via a dynamic linker call, which put the ctor/dtor issue in the
hands of the code which made the dl_open calls.  The second scheme was a poor
man's shared library scheme using ld -A.  I don't remember what we did for
ctors/dtors with the ld -A scheme.



  >  > Do we have a .init section for just the .o?  If so, then ignore this
  >  > issue.
  > 
  > We have an .init section; we don't have the _init function if we don't link
  > against crt[in].o.
OK.  Let's consider this a non-issue for ELF.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < u9yalyi3t6.fsf@yorick.cygnus.com >you write:
  > We have never supported running ctors for a single .o, and I don't see any
  > reason to start.  I've never heard of loading a single .o dynamically
  > without linking it into a shared object.
I was doing this in the early 90s.  Two schemes, one involved sucking
in the .o via a dynamic linker call, which put the ctor/dtor issue in the
hands of the code which made the dl_open calls.  The second scheme was a poor
man's shared library scheme using ld -A.  I don't remember what we did for
ctors/dtors with the ld -A scheme.



  >  > Do we have a .init section for just the .o?  If so, then ignore this
  >  > issue.
  > 
  > We have an .init section; we don't have the _init function if we don't link
  > against crt[in].o.
OK.  Let's consider this a non-issue for ELF.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de >you write:
 >> For ELF targets, do you really think this is a widely-used approach?

 > Widely used is not the criteria.  Lots of things are not widely used, but
 > we still have to support them.

We have never supported running ctors for a single .o, and I don't see any
reason to start.  I've never heard of loading a single .o dynamically
without linking it into a shared object.

 >> If you insist on loading relocatable ELF objects dynamically, you
 >> still can do that: just locate and execute the .init section. No
 >> symbol name needed.

 > Do we have a .init section for just the .o?  If so, then ignore this issue.

We have an .init section; we don't have the _init function if we don't link
against crt[in].o.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> At one time it was possible to build a .o and suck it into your address
> space via dynamic loader calls.  And if the .o has static ctors/dtors, the
> application is responsible for firing them -- and to do so it must be able
> to query the dynamic loader for predictable symbol names.

For ELF targets, do you really think this is a widely-used approach?
I'd rather think you'd typically use -ldl and dlopen, which means that
you have to produce a shared library first. If you do that, libdl will
call the constructors even though it doesn't have a symbol name.

If you insist on loading relocatable ELF objects dynamically, you
still can do that: just locate and execute the .init section. No
symbol name needed.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
> 
>   In message < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de >you write:
>   > I think the minimal solution is to make initializer symbols static on
>   > ELF systems. HJ has a patch, although I haven't reviewed it to see
>   > whether it does what it promises to do.
> I'm not even sure that is correct.
> 
> At one time it was possible to build a .o and suck it into your address
> space via dynamic loader calls.  And if the .o has static ctors/dtors, the
> application is responsible for firing them -- and to do so it must be able
> to query the dynamic loader for predictable symbol names.
> 

Now you are talking non-standard stuff here. I can say it is up to
the application to figure out those .ctor/.dtor sections and call
those .ctor/.dtor sections at the appropriate time. All the information
is there. The ELF linker uses it. So can the application.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> 
> 
>   In message < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de >you write:
>   > I think the minimal solution is to make initializer symbols static on
>   > ELF systems. HJ has a patch, although I haven't reviewed it to see
>   > whether it does what it promises to do.
> I'm not even sure that is correct.
> 
> At one time it was possible to build a .o and suck it into your address
> space via dynamic loader calls.  And if the .o has static ctors/dtors, the
> application is responsible for firing them -- and to do so it must be able
> to query the dynamic loader for predictable symbol names.
> 

Now you are talking non-standard stuff here. I can say it is up to
the application to figure out those .ctor/.dtor sections and call
those .ctor/.dtor sections at the appropriate time. All the information
is there. The ELF linker uses it. So can the application.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de >you write:
  > I think the minimal solution is to make initializer symbols static on
  > ELF systems. HJ has a patch, although I haven't reviewed it to see
  > whether it does what it promises to do.
I'm not even sure that is correct.

At one time it was possible to build a .o and suck it into your address
space via dynamic loader calls.  And if the .o has static ctors/dtors, the
application is responsible for firing them -- and to do so it must be able
to query the dynamic loader for predictable symbol names.

It's basically the same problem we have with shared libraries for non-ELF
targets.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
> concrete yet.

I think the minimal solution is to make initializer symbols static on
ELF systems. HJ has a patch, although I haven't reviewed it to see
whether it does what it promises to do.

If somebody can propose a patch that produces significantly
more-unique symbols than the current code, this should also go into 1.2.
In this respect, HJ's other patch does not qualify, IMHO.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

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

 > I think the minimal solution is to make initializer symbols static on
 > ELF systems.

This seems reasonable.

 > If somebody can propose a patch that produces significantly
 > more-unique symbols than the current code, this should also go into 1.2.

I think the current development code produces adequately unique symbols,
through randomness.  Cases where such disambiguation are rare in any case;
they only occur when the translation units don't contain any symbols known
to be unique, which should not occur often in real code.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

>  > If somebody can propose a patch that produces significantly
>  > more-unique symbols than the current code, this should also go into 1.2.
> 
> I think the current development code produces adequately unique symbols,
> through randomness.  Cases where such disambiguation are rare in any case;
> they only occur when the translation units don't contain any symbols known
> to be unique, which should not occur often in real code.
> 

I looked at the code. It is better than 1.1.1. But it still can be
improved. If noone does anything to it, I will include my unique_string
patch in egcs 1.1.2/Linux.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

>  > If somebody can propose a patch that produces significantly
>  > more-unique symbols than the current code, this should also go into 1.2.
> 
> I think the current development code produces adequately unique symbols,
> through randomness.  Cases where such disambiguation are rare in any case;
> they only occur when the translation units don't contain any symbols known
> to be unique, which should not occur often in real code.
> 

I looked at the code. It is better than 1.1.1. But it still can be
improved. If noone does anything to it, I will include my unique_string
patch in egcs 1.1.2/Linux.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jason Merrill]

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

 > I think the minimal solution is to make initializer symbols static on
 > ELF systems.

This seems reasonable.

 > If somebody can propose a patch that produces significantly
 > more-unique symbols than the current code, this should also go into 1.2.

I think the current development code produces adequately unique symbols,
through randomness.  Cases where such disambiguation are rare in any case;
they only occur when the translation units don't contain any symbols known
to be unique, which should not occur often in real code.

Jason

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m108PtF-00038sC@ocean.lucon.org >you write:
  > My proposal does have some limitations. I hope someone can come
  > up with a better solution. This serious bug must be fixed in
  > egcs 1.1.2. The sooner, the better.
So what is the consensus solution for egcs-1.1.2?  I haven't seen anything
concrete yet.


jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > How about we use
> > 
> > 	machinename+pid+filename+strftime+staticcounter+randomstuff
> > 
> > The possiblility for clash should be very low. I'd like to see it
> > be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.
> 
> I just had a complaint of somebody running into the same problem,
> different scenario:
> 
> He had a number of shared libraries, all starting with the same global
> function. Of course, this is ill-formed (duplicate definitions), but
> the linker didn't complain, so he thought it's all-right. But it
> wasn't: g++ keyed initializers to this function, and the same
> initializer got invoked twice; another initializer wasn't called.
> 
> So I now think that the initializer symbols should be static if we are
> not collect2ing them. 

That is what I have been saying all along.

> 
> Still, coming up with a better 'unique hash' is worthwhile. It should
> be well-designed though: We had several attempts to do it right, and
> still didn't. In your proposal, I see a number of problems:
> 
> a) pid, randomstuff might not be available on all systems. In
>    particular, systems that don't get initializers right probably
>    don't have a number of other things.
> 
> b) Don't produce too long strings. It might exceed assembler
>    restrictions.
> 

My proposal does have some limitations. I hope someone can come
up with a better solution. This serious bug must be fixed in
egcs 1.1.2. The sooner, the better.

Please remember we need a universal unique hash for every different
file on every single machine for the same platform. It is a tough
one. But we have to do it.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> How about we use
> 
> 	machinename+pid+filename+strftime+staticcounter+randomstuff
> 
> The possiblility for clash should be very low. I'd like to see it
> be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.

I just had a complaint of somebody running into the same problem,
different scenario:

He had a number of shared libraries, all starting with the same global
function. Of course, this is ill-formed (duplicate definitions), but
the linker didn't complain, so he thought it's all-right. But it
wasn't: g++ keyed initializers to this function, and the same
initializer got invoked twice; another initializer wasn't called.

So I now think that the initializer symbols should be static if we are
not collect2ing them. 

Still, coming up with a better 'unique hash' is worthwhile. It should
be well-designed though: We had several attempts to do it right, and
still didn't. In your proposal, I see a number of problems:

a) pid, randomstuff might not be available on all systems. In
   particular, systems that don't get initializers right probably
   don't have a number of other things.

b) Don't produce too long strings. It might exceed assembler
   restrictions.

Regards,
Martin
 

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > Do 'D' and 'I' have to be global?
> 
> I'm not sure. As you've found, they don't have to be for ELF. I don't
> know what the rationale was for making them global; it seems this
> knowledge is lost...
> 

collect2 is used for globcl ctors/dtors on some systems.

> > I am not sure if we should worry about anonymous namespaces. What
> > will happen when 2 anonymous namespaces have the same name?
> 
> Bad things. Anonymous namespaces allow you to put
> 
> namespace{
>   int dummy;
> }
> 
> into a header file, and you should get a different variable in each
> object file. More importantly, you can do
> 
> namespace{
>   class Handle{
>     Handle(){}
>   };
> }
> 
> in an implementation and expect that it won't clash with somebody
> else's Handle class. If the two anonymous namespaces have the same
> name, you'll get a clash.

How about we use

	machinename+pid+filename+strftime+staticcounter+randomstuff

The possiblility for clash should be very low. I'd like to see it
be fixed in egcs 1.1.2. If not, I will fix it in egcs 1.1.2/Linux.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902012314.AAA00681@mira.isdn.cs.tu-berlin.de >you write:
  > > Do 'D' and 'I' have to be global?
  > 
  > I'm not sure. As you've found, they don't have to be for ELF. I don't
  > know what the rationale was for making them global; it seems this
  > knowledge is lost...
I haven't followed this whole discussion, so maybe I'm completely off base
with the discussion (also allow that I don't use C++ enough to always know
what y'all are talking about :-), but a shared library initializer routine
must be global.

Consider a non-ELF system where the shared library is loaded explicitly at
run time by the main program.

The main program is responsible for calling the shared library's initializer 
routine to fire the global ctors/dtors.

To do that the program has to query the dynamic linker to see if the library
has a function with the (well known) initializer name which typically has the
form _GLOBAL__FI_<library_name>.  If the initializer function is static, then
we lose.

If you are talking about something different, then ignore me :-)

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> I haven't followed this whole discussion, so maybe I'm completely off base
> with the discussion (also allow that I don't use C++ enough to always know
> what y'all are talking about :-), but a shared library initializer routine
> must be global.
> 
> Consider a non-ELF system where the shared library is loaded explicitly at
> run time by the main program.

Yes, non-ELF systems are a problem, and whatever the fix we find,
we'll also find a way to break it.

What HJ and I now agree on is that we should fix this problem on ELF
systems for good, regardless of the problems experienced on other
systems. So on ELF systems (and other systems with 'real' initializer
functionality), the global ctor function does not need to be external.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> I haven't followed this whole discussion, so maybe I'm completely off base
> with the discussion (also allow that I don't use C++ enough to always know
> what y'all are talking about :-), but a shared library initializer routine
> must be global.
> 
> Consider a non-ELF system where the shared library is loaded explicitly at
> run time by the main program.

Yes, non-ELF systems are a problem, and whatever the fix we find,
we'll also find a way to break it.

What HJ and I now agree on is that we should fix this problem on ELF
systems for good, regardless of the problems experienced on other
systems. So on ELF systems (and other systems with 'real' initializer
functionality), the global ctor function does not need to be external.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < 199902012314.AAA00681@mira.isdn.cs.tu-berlin.de >you write:
  > > Do 'D' and 'I' have to be global?
  > 
  > I'm not sure. As you've found, they don't have to be for ELF. I don't
  > know what the rationale was for making them global; it seems this
  > knowledge is lost...
I haven't followed this whole discussion, so maybe I'm completely off base
with the discussion (also allow that I don't use C++ enough to always know
what y'all are talking about :-), but a shared library initializer routine
must be global.

Consider a non-ELF system where the shared library is loaded explicitly at
run time by the main program.

The main program is responsible for calling the shared library's initializer 
routine to fire the global ctors/dtors.

To do that the program has to query the dynamic linker to see if the library
has a function with the (well known) initializer name which typically has the
form _GLOBAL__FI_<library_name>.  If the initializer function is static, then
we lose.

If you are talking about something different, then ignore me :-)

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Martin v. Loewis]

> Do 'D' and 'I' have to be global?

I'm not sure. As you've found, they don't have to be for ELF. I don't
know what the rationale was for making them global; it seems this
knowledge is lost...

> I am not sure if we should worry about anonymous namespaces. What
> will happen when 2 anonymous namespaces have the same name?

Bad things. Anonymous namespaces allow you to put

namespace{
  int dummy;
}

into a header file, and you should get a different variable in each
object file. More importantly, you can do

namespace{
  class Handle{
    Handle(){}
  };
}

in an implementation and expect that it won't clash with somebody
else's Handle class. If the two anonymous namespaces have the same
name, you'll get a clash.

Regards,
Martin

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> > 1. Can we identify the cases where get_file_function_name_long () is
> > called to generate a name for a global function unique to the
> > resulting executable binary and all the shared libraries it uses?
> 
> There are currently three different 'type' arguments passed to that
> function, 'D', 'I', and 'N'. For 'D' and 'I', additional mangling
> might indicate the initializer priority. For 'N', the resulting name
> will be an anonymous namespace.

Do 'D' and 'I' have to be global?

> 
> > 2. Do they have to be global?
> 
> In the case of anonymous namespaces, absolutely, yes. I proposed to
> make anonymous namespaces (and everything inside) static at one time,
> but it was decided that this approach would defeat upcoming
> implementations of exported templates.
> 

I am not sure if we should worry about anonymous namespaces. What
will happen when 2 anonymous namespaces have the same name?


-- 
H.J. Lu (hjl@gnu.org)

RE: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[James Mansion]

> H.J.Lu wrote:
> In case of the C++ ctor/dtor, collect2 is not needed for ELF, we can
> make it local. My patch does that. If they have to be global, we can
> add strftime () with hostname in addition to append_random_chars ().
> It should have better chances to be unique. But I really want to get
> rid of the global function all together.

Wouldn't it be as easy to use something closely based on the
algorithm for generating DCE GUIDs?

Even if we have substitute IP address for the MAC address, its still
likely to be pretty good, and is at least in some sense or other
'standard'.  If the platform has a GUID generator, it can be used
directly.

James


Demonstration NTMail - see http://www.ntmail.co.uk

RE: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[James Mansion]

> H.J.Lu wrote:
> In case of the C++ ctor/dtor, collect2 is not needed for ELF, we can
> make it local. My patch does that. If they have to be global, we can
> add strftime () with hostname in addition to append_random_chars ().
> It should have better chances to be unique. But I really want to get
> rid of the global function all together.

Wouldn't it be as easy to use something closely based on the
algorithm for generating DCE GUIDs?

Even if we have substitute IP address for the MAC address, its still
likely to be pretty good, and is at least in some sense or other
'standard'.  If the platform has a GUID generator, it can be used
directly.

James


Demonstration NTMail - see http://www.ntmail.co.uk

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Jeffrey A Law]

  In message < m106iAc-000390C@ocean.lucon.org >you write:
  > > 
  > > On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:
  > > 
  > > > I have no idea if this patch is correct. But it works for me. gcc
  > > > seems to pick a poor choice of function name for global constructors
  > > > and destructors. It may not be unique across files.
  > > 
  > > AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
  > > matter of porting his fix to the branch.
  > > 
  > 
  > I saw the fix. It should be back ported to 1.1.2. However, Jason' fix
  > is not 100% safe since it bets on luck. My second patch is 100% safe.
  > But it only covers ctors/dtors in C++ and only works on ELF.
In what way does it "bets on luck"?

Such statements carry far more weight when you take the time to explain them.

jeff

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[H.J. Lu]

> 
> On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:
> 
> > I have no idea if this patch is correct. But it works for me. gcc
> > seems to pick a poor choice of function name for global constructors
> > and destructors. It may not be unique across files.
> 
> AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
> matter of porting his fix to the branch.
> 

I saw the fix. It should be back ported to 1.1.2. However, Jason' fix
is not 100% safe since it bets on luck. My second patch is 100% safe.
But it only covers ctors/dtors in C++ and only works on ELF.

-- 
H.J. Lu (hjl@gnu.org)

Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[Alexandre Oliva]

On Jan 29, 1999, hjl@varesearch.com (H.J. Lu) wrote:

> I have no idea if this patch is correct. But it works for me. gcc
> seems to pick a poor choice of function name for global constructors
> and destructors. It may not be unique across files.

AFAIR, Jason Merrill had fixed this in the trunk, maybe it's just a
matter of porting his fix to the branch.

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

Re: egcs and linux

[N8TM]

In a message dated 2/16/99 9:59:38 AM Pacific Standard Time,
jbuck@Synopsys.COM writes:

<< HJ writes:
 > I have no problems with making Linux versions of egcs. I am
 > used to it by now :-).
 
 But I do have a problem with it.  (That is, I do have a problem with the
 notion that the version delivered by the egcs team won't work on Linux,
 and that Linux users will have to download a separate HJ version to have
 a working compiler).  Since you provide binary releases and encourage
 people to use them, it's a step away from the notion of free software
 for the community to share and improve.  It conveys the idea that only
 wizards like HJ should attempt to compile the compiler.
 
  >>
egcs has worked fine for me on a mixed up part libc5 part glibc linux.  I have
to assume by "working on linux" people mean able to build specific versions of
the kernel or specific software packages.  Building egcs on linux is not as
tricky as on the other environments I've been trying it on.  I even tried the
NAG f95 beta test and found that egcs fixed as many bugs as it introduced
(using gcc version specific NAG libraries), compared with the recommended
gcc-2.7.2 series compilers.  If the f90/f95 vendors would concentrate on using
egcs-1.1.1 series compilers for back end, they would have a better product.

Re: egcs and linux

[Joe Buck]

> << HJ writes:
>  > I have no problems with making Linux versions of egcs. I am
>  > used to it by now :-).

I wrote:
>  But I do have a problem with it....

> egcs has worked fine for me on a mixed up part libc5 part glibc linux.

Yes, it is incorrect to say "it doesn't work", rather that some users
with some library configurations have had trouble with certain specific
programs.

Re: egcs and linux

[Joe Buck]

> << HJ writes:
>  > I have no problems with making Linux versions of egcs. I am
>  > used to it by now :-).

I wrote:
>  But I do have a problem with it....

> egcs has worked fine for me on a mixed up part libc5 part glibc linux.

Yes, it is incorrect to say "it doesn't work", rather that some users
with some library configurations have had trouble with certain specific
programs.

Re: egcs and linux

[N8TM]

In a message dated 2/16/99 9:59:38 AM Pacific Standard Time,
jbuck@Synopsys.COM writes:

<< HJ writes:
 > I have no problems with making Linux versions of egcs. I am
 > used to it by now :-).
 
 But I do have a problem with it.  (That is, I do have a problem with the
 notion that the version delivered by the egcs team won't work on Linux,
 and that Linux users will have to download a separate HJ version to have
 a working compiler).  Since you provide binary releases and encourage
 people to use them, it's a step away from the notion of free software
 for the community to share and improve.  It conveys the idea that only
 wizards like HJ should attempt to compile the compiler.
 
  >>
egcs has worked fine for me on a mixed up part libc5 part glibc linux.  I have
to assume by "working on linux" people mean able to build specific versions of
the kernel or specific software packages.  Building egcs on linux is not as
tricky as on the other environments I've been trying it on.  I even tried the
NAG f95 beta test and found that egcs fixed as many bugs as it introduced
(using gcc version specific NAG libraries), compared with the recommended
gcc-2.7.2 series compilers.  If the f90/f95 vendors would concentrate on using
egcs-1.1.1 series compilers for back end, they would have a better product.