* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 @ 1999-01-29 17:26 H.J. Lu 1999-01-30 12:51 ` Alexandre Oliva 0 siblings, 1 reply; 210+ messages in thread From: H.J. Lu @ 1999-01-29 17:26 UTC (permalink / raw) To: sb; +Cc: egcs 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: ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-29 17:26 multiple definitions of 'xxx keyed to...' in egcs-1.1.1 H.J. Lu @ 1999-01-30 12:51 ` Alexandre Oliva 1999-01-30 13:44 ` H.J. Lu 1999-01-31 23:58 ` Alexandre Oliva 0 siblings, 2 replies; 210+ messages in thread From: Alexandre Oliva @ 1999-01-30 12:51 UTC (permalink / raw) To: H.J. Lu, jason; +Cc: sb, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-30 12:51 ` Alexandre Oliva @ 1999-01-30 13:44 ` H.J. Lu 1999-01-30 18:38 ` Jeffrey A Law 1999-01-31 23:58 ` H.J. Lu 1999-01-31 23:58 ` Alexandre Oliva 1 sibling, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-01-30 13:44 UTC (permalink / raw) To: Alexandre Oliva; +Cc: jason, egcs > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-30 13:44 ` H.J. Lu @ 1999-01-30 18:38 ` Jeffrey A Law 1999-01-31 9:28 ` H.J. Lu 1999-01-31 23:58 ` Jeffrey A Law 1999-01-31 23:58 ` H.J. Lu 1 sibling, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-01-30 18:38 UTC (permalink / raw) To: H.J. Lu; +Cc: Alexandre Oliva, jason, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-30 18:38 ` Jeffrey A Law @ 1999-01-31 9:28 ` H.J. Lu 1999-01-31 23:58 ` Martin v. Loewis 1999-02-01 7:03 ` James Mansion 1999-01-31 23:58 ` Jeffrey A Law 1 sibling, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-01-31 9:28 UTC (permalink / raw) To: law; +Cc: egcs > > > 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-31 9:28 ` H.J. Lu @ 1999-01-31 23:58 ` Martin v. Loewis 1999-02-01 7:02 ` H.J. Lu 1999-02-01 7:03 ` James Mansion 1 sibling, 1 reply; 210+ messages in thread From: Martin v. Loewis @ 1999-01-31 23:58 UTC (permalink / raw) To: hjl; +Cc: law, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-31 23:58 ` Martin v. Loewis @ 1999-02-01 7:02 ` H.J. Lu [not found] ` < m107Krt-00038sC@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 0 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-01 7:02 UTC (permalink / raw) To: Martin v. Loewis; +Cc: law, egcs > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m107Krt-00038sC@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m107Krt-00038sC@ocean.lucon.org > @ 1999-02-01 15:22 ` Martin v. Loewis [not found] ` < 199902012314.AAA00681@mira.isdn.cs.tu-berlin.de > 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 2 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-01 15:22 UTC (permalink / raw) To: hjl; +Cc: law, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902012314.AAA00681@mira.isdn.cs.tu-berlin.de >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902012314.AAA00681@mira.isdn.cs.tu-berlin.de > @ 1999-02-02 7:12 ` H.J. Lu [not found] ` < m107hUo-000392C@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 1999-02-13 11:25 ` Jeffrey A Law 1 sibling, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-02 7:12 UTC (permalink / raw) To: Martin v. Loewis; +Cc: law, egcs > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m107hUo-000392C@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m107hUo-000392C@ocean.lucon.org > @ 1999-02-02 14:22 ` Martin v. Loewis [not found] ` < 199902022216.XAA01250@mira.isdn.cs.tu-berlin.de > 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 2 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-02 14:22 UTC (permalink / raw) To: hjl; +Cc: law, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902022216.XAA01250@mira.isdn.cs.tu-berlin.de >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902022216.XAA01250@mira.isdn.cs.tu-berlin.de > @ 1999-02-04 6:36 ` H.J. Lu [not found] ` < m108PtF-00038sC@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 0 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-04 6:36 UTC (permalink / raw) To: Martin v. Loewis; +Cc: law, egcs > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m108PtF-00038sC@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m108PtF-00038sC@ocean.lucon.org > @ 1999-02-13 11:26 ` Jeffrey A Law [not found] ` < 12451.918933918@hurl.cygnus.com > ` (2 more replies) 0 siblings, 3 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-13 11:26 UTC (permalink / raw) To: H.J. Lu; +Cc: Martin v. Loewis, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 12451.918933918@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 12451.918933918@hurl.cygnus.com > @ 1999-02-13 12:13 ` Martin v. Loewis [not found] ` < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de > 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 2 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-13 12:13 UTC (permalink / raw) To: law; +Cc: hjl, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de > @ 1999-02-13 15:16 ` H.J. Lu [not found] ` < m10BoHn-000392C@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 1999-02-15 22:50 ` Jeffrey A Law 1 sibling, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-13 15:16 UTC (permalink / raw) To: Martin v. Loewis; +Cc: law, egcs > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10BoHn-000392C@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10BoHn-000392C@ocean.lucon.org > @ 1999-02-13 15:21 ` Jeffrey A Law [not found] ` < 13364.918948012@hurl.cygnus.com > ` (2 more replies) 0 siblings, 3 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-13 15:21 UTC (permalink / raw) To: H.J. Lu; +Cc: Martin v. Loewis, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 13364.918948012@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 13364.918948012@hurl.cygnus.com > @ 1999-02-13 15:41 ` H.J. Lu [not found] ` < m10Boh4-000392C@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 0 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-13 15:41 UTC (permalink / raw) To: law; +Cc: martin, egcs > > > 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10Boh4-000392C@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10Boh4-000392C@ocean.lucon.org > @ 1999-02-13 21:42 ` Jeffrey A Law [not found] ` < 13959.918970867@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-13 21:42 UTC (permalink / raw) To: H.J. Lu; +Cc: martin, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 13959.918970867@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 13959.918970867@hurl.cygnus.com > @ 1999-02-15 17:00 ` H.J. Lu [not found] ` < m10CYsJ-00038sC@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 0 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-15 17:00 UTC (permalink / raw) To: law; +Cc: martin, egcs > > > > 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 ()); } ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10CYsJ-00038sC@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10CYsJ-00038sC@ocean.lucon.org > @ 1999-02-15 17:46 ` Mark Mitchell [not found] ` < 199902160149.RAA28975@adsl-206-170-148-33.dsl.pacbell.net > 1999-02-28 22:53 ` Mark Mitchell 0 siblings, 2 replies; 210+ messages in thread From: Mark Mitchell @ 1999-02-15 17:46 UTC (permalink / raw) To: hjl; +Cc: law, martin, egcs >>>>> "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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902160149.RAA28975@adsl-206-170-148-33.dsl.pacbell.net >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902160149.RAA28975@adsl-206-170-148-33.dsl.pacbell.net > @ 1999-02-15 17:50 ` H.J. Lu [not found] ` < m10CZeU-00038sC@ocean.lucon.org > ` (2 more replies) 0 siblings, 3 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-15 17:50 UTC (permalink / raw) To: mark; +Cc: law, martin, egcs > > >>>>> "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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10CZeU-00038sC@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10CZeU-00038sC@ocean.lucon.org > @ 1999-02-15 18:10 ` Mark Mitchell [not found] ` < 199902160212.SAA29229@adsl-206-170-148-33.dsl.pacbell.net > 1999-02-28 22:53 ` Mark Mitchell 0 siblings, 2 replies; 210+ messages in thread From: Mark Mitchell @ 1999-02-15 18:10 UTC (permalink / raw) To: hjl; +Cc: law, martin, egcs >>>>> "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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902160212.SAA29229@adsl-206-170-148-33.dsl.pacbell.net >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902160212.SAA29229@adsl-206-170-148-33.dsl.pacbell.net > @ 1999-02-17 13:39 ` Kamil Iskra [not found] ` < Pine.LNX.3.96.990217221633.1697A-100000@jinks.home > 1999-02-28 22:53 ` Kamil Iskra 0 siblings, 2 replies; 210+ messages in thread From: Kamil Iskra @ 1999-02-17 13:39 UTC (permalink / raw) To: Mark Mitchell; +Cc: egcs 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 / ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < Pine.LNX.3.96.990217221633.1697A-100000@jinks.home >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < Pine.LNX.3.96.990217221633.1697A-100000@jinks.home > @ 1999-02-17 13:45 ` Zack Weinberg 1999-02-28 22:53 ` Zack Weinberg 0 siblings, 1 reply; 210+ messages in thread From: Zack Weinberg @ 1999-02-17 13:45 UTC (permalink / raw) To: Kamil Iskra; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-17 13:45 ` Zack Weinberg @ 1999-02-28 22:53 ` Zack Weinberg 0 siblings, 0 replies; 210+ messages in thread From: Zack Weinberg @ 1999-02-28 22:53 UTC (permalink / raw) To: Kamil Iskra; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-17 13:39 ` Kamil Iskra [not found] ` < Pine.LNX.3.96.990217221633.1697A-100000@jinks.home > @ 1999-02-28 22:53 ` Kamil Iskra 1 sibling, 0 replies; 210+ messages in thread From: Kamil Iskra @ 1999-02-28 22:53 UTC (permalink / raw) To: Mark Mitchell; +Cc: egcs 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 / ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-15 18:10 ` Mark Mitchell [not found] ` < 199902160212.SAA29229@adsl-206-170-148-33.dsl.pacbell.net > @ 1999-02-28 22:53 ` Mark Mitchell 1 sibling, 0 replies; 210+ messages in thread From: Mark Mitchell @ 1999-02-28 22:53 UTC (permalink / raw) To: hjl; +Cc: law, martin, egcs >>>>> "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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: <199902160212.SAA29229.cygnus.egcs@adsl-206-170-148-33.dsl.pacbell.net>]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` <199902160212.SAA29229.cygnus.egcs@adsl-206-170-148-33.dsl.pacbell.net> @ 1999-02-16 10:51 ` Jason Merrill [not found] ` < u9ww1ii3mw.fsf@yorick.cygnus.com > 1999-02-28 22:53 ` Jason Merrill 0 siblings, 2 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-16 10:51 UTC (permalink / raw) To: mark; +Cc: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < u9ww1ii3mw.fsf@yorick.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < u9ww1ii3mw.fsf@yorick.cygnus.com > @ 1999-02-16 11:29 ` Mark Mitchell 1999-02-17 0:26 ` Steinar Bang 1999-02-28 22:53 ` Mark Mitchell 1999-02-16 23:23 ` Jeffrey A Law 1 sibling, 2 replies; 210+ messages in thread From: Mark Mitchell @ 1999-02-16 11:29 UTC (permalink / raw) To: jason; +Cc: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 11:29 ` Mark Mitchell @ 1999-02-17 0:26 ` Steinar Bang 1999-02-28 22:53 ` Steinar Bang 1999-02-28 22:53 ` Mark Mitchell 1 sibling, 1 reply; 210+ messages in thread From: Steinar Bang @ 1999-02-17 0:26 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-17 0:26 ` Steinar Bang @ 1999-02-28 22:53 ` Steinar Bang 0 siblings, 0 replies; 210+ messages in thread From: Steinar Bang @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 11:29 ` Mark Mitchell 1999-02-17 0:26 ` Steinar Bang @ 1999-02-28 22:53 ` Mark Mitchell 1 sibling, 0 replies; 210+ messages in thread From: Mark Mitchell @ 1999-02-28 22:53 UTC (permalink / raw) To: jason; +Cc: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < u9ww1ii3mw.fsf@yorick.cygnus.com > 1999-02-16 11:29 ` Mark Mitchell @ 1999-02-16 23:23 ` Jeffrey A Law 1999-02-16 23:33 ` Jason Merrill 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-16 23:23 UTC (permalink / raw) To: Jason Merrill; +Cc: mark, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 23:23 ` Jeffrey A Law @ 1999-02-16 23:33 ` Jason Merrill [not found] ` < u9iud1iiwm.fsf@yorick.cygnus.com > 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 2 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-16 23:33 UTC (permalink / raw) To: law; +Cc: mark, egcs >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < u9iud1iiwm.fsf@yorick.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < u9iud1iiwm.fsf@yorick.cygnus.com > @ 1999-02-17 6:49 ` H.J. Lu [not found] ` < m10D8I7-00038sC@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 1999-02-21 20:30 ` Jeffrey A Law 1 sibling, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-17 6:49 UTC (permalink / raw) To: Jason Merrill; +Cc: law, mark, egcs > > >>>>> 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10D8I7-00038sC@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10D8I7-00038sC@ocean.lucon.org > @ 1999-02-17 11:45 ` Jeffrey A Law 1999-02-17 12:38 ` Jason Merrill ` (2 more replies) 0 siblings, 3 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-17 11:45 UTC (permalink / raw) To: H.J. Lu; +Cc: Jason Merrill, mark, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-17 11:45 ` Jeffrey A Law @ 1999-02-17 12:38 ` Jason Merrill [not found] ` < u990dwix4w.fsf@yorick.cygnus.com > 1999-02-28 22:53 ` Jason Merrill [not found] ` < 26163.919280679@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 2 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-17 12:38 UTC (permalink / raw) To: law; +Cc: H.J. Lu, mark, egcs >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < u990dwix4w.fsf@yorick.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < u990dwix4w.fsf@yorick.cygnus.com > @ 1999-02-18 6:42 ` H.J. Lu [not found] ` < m10DUeS-00038sC@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 0 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-18 6:42 UTC (permalink / raw) To: Jason Merrill; +Cc: egcs > > >>>>> 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10DUeS-00038sC@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10DUeS-00038sC@ocean.lucon.org > @ 1999-02-20 12:47 ` Jeffrey A Law [not found] ` < 4798.919543586@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-20 12:47 UTC (permalink / raw) To: H.J. Lu; +Cc: Jason Merrill, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 4798.919543586@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 4798.919543586@hurl.cygnus.com > @ 1999-02-20 12:55 ` H.J. Lu [not found] ` < m10EJQj-000392C@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 1999-02-20 12:58 ` Zack Weinberg 1999-02-20 12:58 ` H.J. Lu 2 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-20 12:55 UTC (permalink / raw) To: law; +Cc: jason, egcs > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10EJQj-000392C@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10EJQj-000392C@ocean.lucon.org > @ 1999-02-20 12:58 ` Jeffrey A Law [not found] ` < 4881.919544286@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-20 12:58 UTC (permalink / raw) To: H.J. Lu; +Cc: jason, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 4881.919544286@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 4881.919544286@hurl.cygnus.com > @ 1999-02-20 13:02 ` H.J. Lu [not found] ` < m10EJXX-000392C@ocean.lucon.org > ` (2 more replies) 0 siblings, 3 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-20 13:02 UTC (permalink / raw) To: law; +Cc: egcs, egcs-patches > > > 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 (); ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10EJXX-000392C@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10EJXX-000392C@ocean.lucon.org > @ 1999-02-20 13:09 ` Jeffrey A Law [not found] ` < 4941.919544939@hurl.cygnus.com > ` (2 more replies) 1999-02-20 13:17 ` Jeffrey A Law ` (2 subsequent siblings) 3 siblings, 3 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-20 13:09 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 4941.919544939@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 4941.919544939@hurl.cygnus.com > @ 1999-02-20 13:12 ` H.J. Lu 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` H.J. Lu 0 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-20 13:12 UTC (permalink / raw) To: law; +Cc: egcs, egcs-patches > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:12 ` H.J. Lu @ 1999-02-28 22:53 ` Jeffrey A Law 1999-02-20 13:33 ` Robert Lipe 1999-02-28 22:53 ` H.J. Lu 1 sibling, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-28 22:53 ` Jeffrey A Law @ 1999-02-20 13:33 ` Robert Lipe [not found] ` < 19990220153254.A8783@rjlhome.sco.com > 1999-02-28 22:53 ` Robert Lipe 0 siblings, 2 replies; 210+ messages in thread From: Robert Lipe @ 1999-02-20 13:33 UTC (permalink / raw) To: law; +Cc: H.J. Lu, egcs, egcs-patches > > > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 19990220153254.A8783@rjlhome.sco.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 19990220153254.A8783@rjlhome.sco.com > @ 1999-02-20 14:36 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-20 14:36 UTC (permalink / raw) To: Robert Lipe; +Cc: H.J. Lu, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 14:36 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Robert Lipe; +Cc: H.J. Lu, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:33 ` Robert Lipe [not found] ` < 19990220153254.A8783@rjlhome.sco.com > @ 1999-02-28 22:53 ` Robert Lipe 1 sibling, 0 replies; 210+ messages in thread From: Robert Lipe @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: H.J. Lu, egcs, egcs-patches > > > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:12 ` H.J. Lu 1999-02-28 22:53 ` Jeffrey A Law @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: egcs, egcs-patches > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:09 ` Jeffrey A Law [not found] ` < 4941.919544939@hurl.cygnus.com > @ 1999-02-22 0:46 ` Andris Pavenis 1999-02-28 22:53 ` Andris Pavenis 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 1 reply; 210+ messages in thread From: Andris Pavenis @ 1999-02-22 0:46 UTC (permalink / raw) To: law, Jeffrey A Law, H.J. Lu; +Cc: egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-22 0:46 ` Andris Pavenis @ 1999-02-28 22:53 ` Andris Pavenis 0 siblings, 0 replies; 210+ messages in thread From: Andris Pavenis @ 1999-02-28 22:53 UTC (permalink / raw) To: law, Jeffrey A Law, H.J. Lu; +Cc: egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:09 ` Jeffrey A Law [not found] ` < 4941.919544939@hurl.cygnus.com > 1999-02-22 0:46 ` Andris Pavenis @ 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10EJXX-000392C@ocean.lucon.org > 1999-02-20 13:09 ` Jeffrey A Law @ 1999-02-20 13:17 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-20 13:34 ` Mumit Khan 1999-02-20 15:35 ` Martin v. Loewis 3 siblings, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-20 13:17 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:17 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10EJXX-000392C@ocean.lucon.org > 1999-02-20 13:09 ` Jeffrey A Law 1999-02-20 13:17 ` Jeffrey A Law @ 1999-02-20 13:34 ` Mumit Khan 1999-02-28 22:53 ` Mumit Khan 1999-02-20 15:35 ` Martin v. Loewis 3 siblings, 1 reply; 210+ messages in thread From: Mumit Khan @ 1999-02-20 13:34 UTC (permalink / raw) To: H.J. Lu; +Cc: law, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:34 ` Mumit Khan @ 1999-02-28 22:53 ` Mumit Khan 0 siblings, 0 replies; 210+ messages in thread From: Mumit Khan @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: law, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10EJXX-000392C@ocean.lucon.org > ` (2 preceding siblings ...) 1999-02-20 13:34 ` Mumit Khan @ 1999-02-20 15:35 ` Martin v. Loewis [not found] ` < 199902202335.AAA06542@mira.isdn.cs.tu-berlin.de > 1999-02-28 22:53 ` Martin v. Loewis 3 siblings, 2 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-20 15:35 UTC (permalink / raw) To: hjl; +Cc: law, egcs, egcs-patches > * 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902202335.AAA06542@mira.isdn.cs.tu-berlin.de >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902202335.AAA06542@mira.isdn.cs.tu-berlin.de > @ 1999-02-20 16:11 ` H.J. Lu [not found] ` < m10EMUB-000392C@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 0 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-20 16:11 UTC (permalink / raw) To: Martin v. Loewis; +Cc: law, egcs, egcs-patches > > > * 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10EMUB-000392C@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10EMUB-000392C@ocean.lucon.org > @ 1999-02-21 15:15 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-21 15:15 UTC (permalink / raw) To: H.J. Lu; +Cc: Martin v. Loewis, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 15:15 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: Martin v. Loewis, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 16:11 ` H.J. Lu [not found] ` < m10EMUB-000392C@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: law, egcs, egcs-patches > > > * 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 15:35 ` Martin v. Loewis [not found] ` < 199902202335.AAA06542@mira.isdn.cs.tu-berlin.de > @ 1999-02-28 22:53 ` Martin v. Loewis 1 sibling, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: hjl; +Cc: law, egcs, egcs-patches > * 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:02 ` H.J. Lu [not found] ` < m10EJXX-000392C@ocean.lucon.org > @ 1999-02-21 13:59 ` Jason Merrill [not found] ` < u9vhgvfmfa.fsf@yorick.cygnus.com > 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` H.J. Lu 2 siblings, 2 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-21 13:59 UTC (permalink / raw) To: H.J. Lu; +Cc: law, egcs, egcs-patches >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < u9vhgvfmfa.fsf@yorick.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < u9vhgvfmfa.fsf@yorick.cygnus.com > @ 1999-02-21 15:22 ` Jeffrey A Law [not found] ` < 7817.919639310@hurl.cygnus.com > ` (2 more replies) 0 siblings, 3 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-21 15:22 UTC (permalink / raw) To: Jason Merrill; +Cc: H.J. Lu, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 7817.919639310@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 7817.919639310@hurl.cygnus.com > @ 1999-02-21 15:28 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-21 15:28 UTC (permalink / raw) To: egcs; +Cc: Jason Merrill, H.J. Lu, egcs, egcs-patches [ 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 15:28 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs; +Cc: Jason Merrill, H.J. Lu, egcs, egcs-patches [ 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 15:22 ` Jeffrey A Law [not found] ` < 7817.919639310@hurl.cygnus.com > @ 1999-02-21 16:16 ` Jason Merrill [not found] ` < u9lnhrfg3k.fsf@yorick.cygnus.com > 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 2 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-21 16:16 UTC (permalink / raw) To: law; +Cc: H.J. Lu, egcs, egcs-patches >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < u9lnhrfg3k.fsf@yorick.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < u9lnhrfg3k.fsf@yorick.cygnus.com > @ 1999-02-21 16:40 ` Jeffrey A Law [not found] ` < 8103.919644009@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-21 16:40 UTC (permalink / raw) To: Jason Merrill; +Cc: H.J. Lu, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 8103.919644009@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 8103.919644009@hurl.cygnus.com > @ 1999-02-21 17:07 ` Richard Henderson [not found] ` < 19990221170738.A22156@cygnus.com > 1999-02-28 22:53 ` Richard Henderson 0 siblings, 2 replies; 210+ messages in thread From: Richard Henderson @ 1999-02-21 17:07 UTC (permalink / raw) To: law, Jason Merrill; +Cc: H.J. Lu, egcs, egcs-patches 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~ ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 19990221170738.A22156@cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 19990221170738.A22156@cygnus.com > @ 1999-02-21 17:16 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-21 17:16 UTC (permalink / raw) To: Richard Henderson; +Cc: Jason Merrill, H.J. Lu, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 17:16 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Richard Henderson; +Cc: Jason Merrill, H.J. Lu, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 17:07 ` Richard Henderson [not found] ` < 19990221170738.A22156@cygnus.com > @ 1999-02-28 22:53 ` Richard Henderson 1 sibling, 0 replies; 210+ messages in thread From: Richard Henderson @ 1999-02-28 22:53 UTC (permalink / raw) To: law, Jason Merrill; +Cc: H.J. Lu, egcs, egcs-patches 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~ ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 16:40 ` Jeffrey A Law [not found] ` < 8103.919644009@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill; +Cc: H.J. Lu, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 16:16 ` Jason Merrill [not found] ` < u9lnhrfg3k.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 1 sibling, 0 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: H.J. Lu, egcs, egcs-patches >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 15:22 ` Jeffrey A Law [not found] ` < 7817.919639310@hurl.cygnus.com > 1999-02-21 16:16 ` Jason Merrill @ 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill; +Cc: H.J. Lu, egcs, egcs-patches 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 13:59 ` Jason Merrill [not found] ` < u9vhgvfmfa.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 1 sibling, 0 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: law, egcs, egcs-patches >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:02 ` H.J. Lu [not found] ` < m10EJXX-000392C@ocean.lucon.org > 1999-02-21 13:59 ` Jason Merrill @ 1999-02-28 22:53 ` H.J. Lu 2 siblings, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: egcs, egcs-patches > > > 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 (); ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 12:58 ` Jeffrey A Law [not found] ` < 4881.919544286@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: jason, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 12:55 ` H.J. Lu [not found] ` < m10EJQj-000392C@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: jason, egcs > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 4798.919543586@hurl.cygnus.com > 1999-02-20 12:55 ` H.J. Lu @ 1999-02-20 12:58 ` Zack Weinberg [not found] ` < 199902202057.PAA22565@blastula.phys.columbia.edu > ` (2 more replies) 1999-02-20 12:58 ` H.J. Lu 2 siblings, 3 replies; 210+ messages in thread From: Zack Weinberg @ 1999-02-20 12:58 UTC (permalink / raw) To: law; +Cc: Jason Merrill, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902202057.PAA22565@blastula.phys.columbia.edu >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902202057.PAA22565@blastula.phys.columbia.edu > @ 1999-02-20 13:28 ` Jeffrey A Law [not found] ` < 5066.919546022@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-20 13:28 UTC (permalink / raw) To: Zack Weinberg; +Cc: Jason Merrill, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 5066.919546022@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 5066.919546022@hurl.cygnus.com > @ 1999-02-20 13:35 ` Zack Weinberg [not found] ` < 199902202135.QAA23017@blastula.phys.columbia.edu > 1999-02-28 22:53 ` Zack Weinberg 1999-02-21 18:22 ` the jackal 1 sibling, 2 replies; 210+ messages in thread From: Zack Weinberg @ 1999-02-20 13:35 UTC (permalink / raw) To: law; +Cc: Jason Merrill, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902202135.QAA23017@blastula.phys.columbia.edu >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902202135.QAA23017@blastula.phys.columbia.edu > @ 1999-02-20 13:42 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-20 15:40 ` Martin v. Loewis 1 sibling, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-20 13:42 UTC (permalink / raw) To: Zack Weinberg; +Cc: Jason Merrill, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:42 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Zack Weinberg; +Cc: Jason Merrill, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902202135.QAA23017@blastula.phys.columbia.edu > 1999-02-20 13:42 ` Jeffrey A Law @ 1999-02-20 15:40 ` Martin v. Loewis [not found] ` < 199902202338.AAA06546@mira.isdn.cs.tu-berlin.de > 1999-02-28 22:53 ` Martin v. Loewis 1 sibling, 2 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-20 15:40 UTC (permalink / raw) To: zack; +Cc: law, jason, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902202338.AAA06546@mira.isdn.cs.tu-berlin.de >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902202338.AAA06546@mira.isdn.cs.tu-berlin.de > @ 1999-02-21 3:45 ` Kamil Iskra [not found] ` < Pine.LNX.3.96.990221120241.903C-100000@jinks.home > 1999-02-28 22:53 ` Kamil Iskra 0 siblings, 2 replies; 210+ messages in thread From: Kamil Iskra @ 1999-02-21 3:45 UTC (permalink / raw) To: Martin v. Loewis; +Cc: egcs 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 / ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < Pine.LNX.3.96.990221120241.903C-100000@jinks.home >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < Pine.LNX.3.96.990221120241.903C-100000@jinks.home > @ 1999-02-21 11:20 ` Martin v. Loewis 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 1 reply; 210+ messages in thread From: Martin v. Loewis @ 1999-02-21 11:20 UTC (permalink / raw) To: kamil; +Cc: egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 11:20 ` Martin v. Loewis @ 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: kamil; +Cc: egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 3:45 ` Kamil Iskra [not found] ` < Pine.LNX.3.96.990221120241.903C-100000@jinks.home > @ 1999-02-28 22:53 ` Kamil Iskra 1 sibling, 0 replies; 210+ messages in thread From: Kamil Iskra @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: egcs 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 / ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 15:40 ` Martin v. Loewis [not found] ` < 199902202338.AAA06546@mira.isdn.cs.tu-berlin.de > @ 1999-02-28 22:53 ` Martin v. Loewis 1 sibling, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: zack; +Cc: law, jason, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:35 ` Zack Weinberg [not found] ` < 199902202135.QAA23017@blastula.phys.columbia.edu > @ 1999-02-28 22:53 ` Zack Weinberg 1 sibling, 0 replies; 210+ messages in thread From: Zack Weinberg @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: Jason Merrill, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 5066.919546022@hurl.cygnus.com > 1999-02-20 13:35 ` Zack Weinberg @ 1999-02-21 18:22 ` the jackal [not found] ` < 19990221211950.B10271@diwanh.stu.rpi.edu > 1999-02-28 22:53 ` the jackal 1 sibling, 2 replies; 210+ messages in thread From: the jackal @ 1999-02-21 18:22 UTC (permalink / raw) To: egcs Warning Could not process message with given Content-Type: multipart/signed; boundary=z6Eq5LdranGa6ru8; micalg=pgp-md5;protocol="application/pgp-signature" ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 19990221211950.B10271@diwanh.stu.rpi.edu >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 19990221211950.B10271@diwanh.stu.rpi.edu > @ 1999-02-21 18:47 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-21 18:47 UTC (permalink / raw) To: the jackal; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 18:47 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: the jackal; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 18:22 ` the jackal [not found] ` < 19990221211950.B10271@diwanh.stu.rpi.edu > @ 1999-02-28 22:53 ` the jackal 1 sibling, 0 replies; 210+ messages in thread From: the jackal @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs 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----- ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:28 ` Jeffrey A Law [not found] ` < 5066.919546022@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Zack Weinberg; +Cc: Jason Merrill, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 12:58 ` Zack Weinberg [not found] ` < 199902202057.PAA22565@blastula.phys.columbia.edu > @ 1999-02-22 0:40 ` Andris Pavenis [not found] ` < 99022210384700.00200@hal > 1999-02-28 22:53 ` Andris Pavenis 1999-02-28 22:53 ` Zack Weinberg 2 siblings, 2 replies; 210+ messages in thread From: Andris Pavenis @ 1999-02-22 0:40 UTC (permalink / raw) To: Zack Weinberg; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 99022210384700.00200@hal >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 99022210384700.00200@hal > @ 1999-02-22 6:59 ` H.J. Lu 1999-02-24 0:18 ` Andris Pavenis 1999-02-28 22:53 ` H.J. Lu 0 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-22 6:59 UTC (permalink / raw) To: Andris Pavenis; +Cc: zack, egcs > > > >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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-22 6:59 ` H.J. Lu @ 1999-02-24 0:18 ` Andris Pavenis 1999-02-28 22:53 ` Andris Pavenis 1999-02-28 22:53 ` H.J. Lu 1 sibling, 1 reply; 210+ messages in thread From: Andris Pavenis @ 1999-02-24 0:18 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-24 0:18 ` Andris Pavenis @ 1999-02-28 22:53 ` Andris Pavenis 0 siblings, 0 replies; 210+ messages in thread From: Andris Pavenis @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-22 6:59 ` H.J. Lu 1999-02-24 0:18 ` Andris Pavenis @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Andris Pavenis; +Cc: zack, egcs > > > >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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-22 0:40 ` Andris Pavenis [not found] ` < 99022210384700.00200@hal > @ 1999-02-28 22:53 ` Andris Pavenis 1 sibling, 0 replies; 210+ messages in thread From: Andris Pavenis @ 1999-02-28 22:53 UTC (permalink / raw) To: Zack Weinberg; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 12:58 ` Zack Weinberg [not found] ` < 199902202057.PAA22565@blastula.phys.columbia.edu > 1999-02-22 0:40 ` Andris Pavenis @ 1999-02-28 22:53 ` Zack Weinberg 2 siblings, 0 replies; 210+ messages in thread From: Zack Weinberg @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: Jason Merrill, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 4798.919543586@hurl.cygnus.com > 1999-02-20 12:55 ` H.J. Lu 1999-02-20 12:58 ` Zack Weinberg @ 1999-02-20 12:58 ` H.J. Lu [not found] ` < m10EJTY-000392C@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 2 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-20 12:58 UTC (permalink / raw) To: law; +Cc: egcs > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10EJTY-000392C@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10EJTY-000392C@ocean.lucon.org > @ 1999-02-20 13:04 ` Jeffrey A Law [not found] ` < 4923.919544645@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-20 13:04 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 4923.919544645@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 4923.919544645@hurl.cygnus.com > @ 1999-02-20 13:15 ` H.J. Lu [not found] ` < m10EJjp-000392C@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 0 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-20 13:15 UTC (permalink / raw) To: law; +Cc: egcs > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10EJjp-000392C@ocean.lucon.org >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < m10EJjp-000392C@ocean.lucon.org > @ 1999-02-20 15:40 ` Martin v. Loewis 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 1 reply; 210+ messages in thread From: Martin v. Loewis @ 1999-02-20 15:40 UTC (permalink / raw) To: hjl; +Cc: law, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 15:40 ` Martin v. Loewis @ 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: hjl; +Cc: law, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:15 ` H.J. Lu [not found] ` < m10EJjp-000392C@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: egcs > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 13:04 ` Jeffrey A Law [not found] ` < 4923.919544645@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 12:58 ` H.J. Lu [not found] ` < m10EJTY-000392C@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: egcs > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-20 12:47 ` Jeffrey A Law [not found] ` < 4798.919543586@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: Jason Merrill, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-18 6:42 ` H.J. Lu [not found] ` < m10DUeS-00038sC@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill; +Cc: egcs > > >>>>> 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-17 12:38 ` Jason Merrill [not found] ` < u990dwix4w.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 1 sibling, 0 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: H.J. Lu, mark, egcs >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 26163.919280679@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 26163.919280679@hurl.cygnus.com > @ 1999-02-17 15:45 ` Martin v. Loewis [not found] ` < 199902172339.AAA01000@mira.isdn.cs.tu-berlin.de > 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 2 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-17 15:45 UTC (permalink / raw) To: law; +Cc: hjl, jason, mark, egcs [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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902172339.AAA01000@mira.isdn.cs.tu-berlin.de >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902172339.AAA01000@mira.isdn.cs.tu-berlin.de > @ 1999-02-17 15:48 ` Jeffrey A Law [not found] ` < 26749.919295221@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-17 15:48 UTC (permalink / raw) To: Martin v. Loewis; +Cc: hjl, jason, mark, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 26749.919295221@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 26749.919295221@hurl.cygnus.com > @ 1999-02-17 16:37 ` Martin v. Loewis 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 1 reply; 210+ messages in thread From: Martin v. Loewis @ 1999-02-17 16:37 UTC (permalink / raw) To: law; +Cc: hjl, jason, mark, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-17 16:37 ` Martin v. Loewis @ 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: hjl, jason, mark, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-17 15:48 ` Jeffrey A Law [not found] ` < 26749.919295221@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: hjl, jason, mark, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-17 15:45 ` Martin v. Loewis [not found] ` < 199902172339.AAA01000@mira.isdn.cs.tu-berlin.de > @ 1999-02-28 22:53 ` Martin v. Loewis 1 sibling, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: hjl, jason, mark, egcs [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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-17 11:45 ` Jeffrey A Law 1999-02-17 12:38 ` Jason Merrill [not found] ` < 26163.919280679@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: Jason Merrill, mark, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-17 6:49 ` H.J. Lu [not found] ` < m10D8I7-00038sC@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill; +Cc: law, mark, egcs > > >>>>> 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < u9iud1iiwm.fsf@yorick.cygnus.com > 1999-02-17 6:49 ` H.J. Lu @ 1999-02-21 20:30 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-21 20:30 UTC (permalink / raw) To: Jason Merrill; +Cc: mark, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-21 20:30 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill; +Cc: mark, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 23:33 ` Jason Merrill [not found] ` < u9iud1iiwm.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 1 sibling, 0 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: mark, egcs >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 23:23 ` Jeffrey A Law 1999-02-16 23:33 ` Jason Merrill @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill; +Cc: mark, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 10:51 ` Jason Merrill [not found] ` < u9ww1ii3mw.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 1 sibling, 0 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: mark; +Cc: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-15 17:50 ` H.J. Lu [not found] ` < m10CZeU-00038sC@ocean.lucon.org > [not found] ` <199902160212.SAA29229.cygnus.egcs@adsl-206-170-148-33.dsl.pacbell.net> @ 1999-02-28 22:53 ` H.J. Lu 2 siblings, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: mark; +Cc: law, martin, egcs > > >>>>> "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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-15 17:46 ` Mark Mitchell [not found] ` < 199902160149.RAA28975@adsl-206-170-148-33.dsl.pacbell.net > @ 1999-02-28 22:53 ` Mark Mitchell 1 sibling, 0 replies; 210+ messages in thread From: Mark Mitchell @ 1999-02-28 22:53 UTC (permalink / raw) To: hjl; +Cc: law, martin, egcs >>>>> "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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-15 17:00 ` H.J. Lu [not found] ` < m10CYsJ-00038sC@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: martin, egcs > > > > 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 ()); } ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-13 21:42 ` Jeffrey A Law [not found] ` < 13959.918970867@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: martin, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-13 15:41 ` H.J. Lu [not found] ` < m10Boh4-000392C@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: martin, egcs > > > 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* egcs and linux 1999-02-13 15:21 ` Jeffrey A Law [not found] ` < 13364.918948012@hurl.cygnus.com > @ 1999-02-14 4:39 ` Steinar Bang [not found] ` < wh1zjtgnwy.fsf@viffer.oslo.metis.no > 1999-02-28 22:53 ` Steinar Bang 1999-02-28 22:53 ` multiple definitions of 'xxx keyed to...' in egcs-1.1.1 Jeffrey A Law 2 siblings, 2 replies; 210+ messages in thread From: Steinar Bang @ 1999-02-14 4:39 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < wh1zjtgnwy.fsf@viffer.oslo.metis.no >]
* Re: egcs and linux [not found] ` < wh1zjtgnwy.fsf@viffer.oslo.metis.no > @ 1999-02-14 7:06 ` Marc Espie 1999-02-14 7:23 ` Steinar Bang 1999-02-28 22:53 ` Marc Espie 1999-02-14 8:00 ` Jeffrey A Law ` (2 subsequent siblings) 3 siblings, 2 replies; 210+ messages in thread From: Marc Espie @ 1999-02-14 7:06 UTC (permalink / raw) To: sb; +Cc: egcs 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... ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 7:06 ` Marc Espie @ 1999-02-14 7:23 ` Steinar Bang [not found] ` < whogmxdn6i.fsf@viffer.oslo.metis.no > 1999-02-28 22:53 ` Steinar Bang 1999-02-28 22:53 ` Marc Espie 1 sibling, 2 replies; 210+ messages in thread From: Steinar Bang @ 1999-02-14 7:23 UTC (permalink / raw) To: egcs >>>>> 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? ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < whogmxdn6i.fsf@viffer.oslo.metis.no >]
* Re: egcs and linux [not found] ` < whogmxdn6i.fsf@viffer.oslo.metis.no > @ 1999-02-14 8:01 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-14 8:01 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 8:01 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 7:23 ` Steinar Bang [not found] ` < whogmxdn6i.fsf@viffer.oslo.metis.no > @ 1999-02-28 22:53 ` Steinar Bang 1 sibling, 0 replies; 210+ messages in thread From: Steinar Bang @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs >>>>> 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? ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 7:06 ` Marc Espie 1999-02-14 7:23 ` Steinar Bang @ 1999-02-28 22:53 ` Marc Espie 1 sibling, 0 replies; 210+ messages in thread From: Marc Espie @ 1999-02-28 22:53 UTC (permalink / raw) To: sb; +Cc: egcs 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... ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux [not found] ` < wh1zjtgnwy.fsf@viffer.oslo.metis.no > 1999-02-14 7:06 ` Marc Espie @ 1999-02-14 8:00 ` Jeffrey A Law 1999-02-14 8:05 ` Steinar Bang 1999-02-28 22:53 ` Jeffrey A Law 1999-02-14 9:39 ` Scott McDermott 1999-02-14 22:47 ` Joe Buck 3 siblings, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-14 8:00 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 8:00 ` Jeffrey A Law @ 1999-02-14 8:05 ` Steinar Bang [not found] ` < whemntdl8m.fsf@viffer.oslo.metis.no > 1999-02-28 22:53 ` Steinar Bang 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 2 replies; 210+ messages in thread From: Steinar Bang @ 1999-02-14 8:05 UTC (permalink / raw) To: egcs >>>>> 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < whemntdl8m.fsf@viffer.oslo.metis.no >]
* Re: egcs and linux [not found] ` < whemntdl8m.fsf@viffer.oslo.metis.no > @ 1999-02-14 8:10 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-14 8:10 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 8:10 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 8:05 ` Steinar Bang [not found] ` < whemntdl8m.fsf@viffer.oslo.metis.no > @ 1999-02-28 22:53 ` Steinar Bang 1 sibling, 0 replies; 210+ messages in thread From: Steinar Bang @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs >>>>> 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 8:00 ` Jeffrey A Law 1999-02-14 8:05 ` Steinar Bang @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux [not found] ` < wh1zjtgnwy.fsf@viffer.oslo.metis.no > 1999-02-14 7:06 ` Marc Espie 1999-02-14 8:00 ` Jeffrey A Law @ 1999-02-14 9:39 ` Scott McDermott 1999-02-14 10:00 ` Steinar Bang 1999-02-28 22:53 ` Scott McDermott 1999-02-14 22:47 ` Joe Buck 3 siblings, 2 replies; 210+ messages in thread From: Scott McDermott @ 1999-02-14 9:39 UTC (permalink / raw) To: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 9:39 ` Scott McDermott @ 1999-02-14 10:00 ` Steinar Bang 1999-02-28 22:53 ` Steinar Bang 1999-02-28 22:53 ` Scott McDermott 1 sibling, 1 reply; 210+ messages in thread From: Steinar Bang @ 1999-02-14 10:00 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 10:00 ` Steinar Bang @ 1999-02-28 22:53 ` Steinar Bang 0 siblings, 0 replies; 210+ messages in thread From: Steinar Bang @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 9:39 ` Scott McDermott 1999-02-14 10:00 ` Steinar Bang @ 1999-02-28 22:53 ` Scott McDermott 1 sibling, 0 replies; 210+ messages in thread From: Scott McDermott @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux [not found] ` < wh1zjtgnwy.fsf@viffer.oslo.metis.no > ` (2 preceding siblings ...) 1999-02-14 9:39 ` Scott McDermott @ 1999-02-14 22:47 ` Joe Buck [not found] ` < 199902150645.WAA17085@atrus.synopsys.com > 1999-02-28 22:53 ` Joe Buck 3 siblings, 2 replies; 210+ messages in thread From: Joe Buck @ 1999-02-14 22:47 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902150645.WAA17085@atrus.synopsys.com >]
* Re: egcs and linux [not found] ` < 199902150645.WAA17085@atrus.synopsys.com > @ 1999-02-15 17:40 ` H.J. Lu [not found] ` < m10CZUe-00038sC@ocean.lucon.org > 1999-02-28 22:53 ` H.J. Lu 0 siblings, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-15 17:40 UTC (permalink / raw) To: Joe Buck; +Cc: sb, egcs > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < m10CZUe-00038sC@ocean.lucon.org >]
* Re: egcs and linux [not found] ` < m10CZUe-00038sC@ocean.lucon.org > @ 1999-02-16 9:58 ` Joe Buck [not found] ` < 199902161756.JAA18794@atrus.synopsys.com > 1999-02-28 22:53 ` Joe Buck 1999-02-16 10:06 ` Joe Buck 1 sibling, 2 replies; 210+ messages in thread From: Joe Buck @ 1999-02-16 9:58 UTC (permalink / raw) To: H.J. Lu; +Cc: jbuck, sb, egcs 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902161756.JAA18794@atrus.synopsys.com >]
* Re: egcs and linux [not found] ` < 199902161756.JAA18794@atrus.synopsys.com > @ 1999-02-16 20:13 ` H.J. Lu 1999-02-16 20:55 ` Scott Bambrough 1999-02-28 22:53 ` H.J. Lu 1999-02-18 15:37 ` Horst von Brand 1 sibling, 2 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-16 20:13 UTC (permalink / raw) To: Joe Buck; +Cc: egcs > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-16 20:13 ` H.J. Lu @ 1999-02-16 20:55 ` Scott Bambrough 1999-02-28 22:53 ` Scott Bambrough 1999-02-28 22:53 ` H.J. Lu 1 sibling, 1 reply; 210+ messages in thread From: Scott Bambrough @ 1999-02-16 20:55 UTC (permalink / raw) To: H.J. Lu; +Cc: Joe Buck, egcs "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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-16 20:55 ` Scott Bambrough @ 1999-02-28 22:53 ` Scott Bambrough 0 siblings, 0 replies; 210+ messages in thread From: Scott Bambrough @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: Joe Buck, egcs "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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-16 20:13 ` H.J. Lu 1999-02-16 20:55 ` Scott Bambrough @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Joe Buck; +Cc: egcs > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux [not found] ` < 199902161756.JAA18794@atrus.synopsys.com > 1999-02-16 20:13 ` H.J. Lu @ 1999-02-18 15:37 ` Horst von Brand 1999-02-28 22:53 ` Horst von Brand 1 sibling, 1 reply; 210+ messages in thread From: Horst von Brand @ 1999-02-18 15:37 UTC (permalink / raw) To: Joe Buck; +Cc: H.J. Lu, egcs [-- 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-18 15:37 ` Horst von Brand @ 1999-02-28 22:53 ` Horst von Brand 0 siblings, 0 replies; 210+ messages in thread From: Horst von Brand @ 1999-02-28 22:53 UTC (permalink / raw) To: Joe Buck; +Cc: H.J. Lu, egcs [-- 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-16 9:58 ` Joe Buck [not found] ` < 199902161756.JAA18794@atrus.synopsys.com > @ 1999-02-28 22:53 ` Joe Buck 1 sibling, 0 replies; 210+ messages in thread From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: jbuck, sb, egcs 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux [not found] ` < m10CZUe-00038sC@ocean.lucon.org > 1999-02-16 9:58 ` Joe Buck @ 1999-02-16 10:06 ` Joe Buck [not found] ` < 199902161805.KAA18983@atrus.synopsys.com > 1999-02-28 22:53 ` Joe Buck 1 sibling, 2 replies; 210+ messages in thread From: Joe Buck @ 1999-02-16 10:06 UTC (permalink / raw) To: H.J. Lu; +Cc: jbuck, sb, egcs 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). ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902161805.KAA18983@atrus.synopsys.com >]
* Re: egcs and linux [not found] ` < 199902161805.KAA18983@atrus.synopsys.com > @ 1999-02-16 20:02 ` H.J. Lu 1999-02-28 22:53 ` H.J. Lu 0 siblings, 1 reply; 210+ messages in thread From: H.J. Lu @ 1999-02-16 20:02 UTC (permalink / raw) To: Joe Buck; +Cc: egcs > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-16 20:02 ` H.J. Lu @ 1999-02-28 22:53 ` H.J. Lu 0 siblings, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Joe Buck; +Cc: egcs > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-16 10:06 ` Joe Buck [not found] ` < 199902161805.KAA18983@atrus.synopsys.com > @ 1999-02-28 22:53 ` Joe Buck 1 sibling, 0 replies; 210+ messages in thread From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: jbuck, sb, egcs 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). ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-15 17:40 ` H.J. Lu [not found] ` < m10CZUe-00038sC@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Joe Buck; +Cc: sb, egcs > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-14 22:47 ` Joe Buck [not found] ` < 199902150645.WAA17085@atrus.synopsys.com > @ 1999-02-28 22:53 ` Joe Buck 1 sibling, 0 replies; 210+ messages in thread From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw) To: Steinar Bang; +Cc: egcs > 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* egcs and linux 1999-02-14 4:39 ` egcs and linux Steinar Bang [not found] ` < wh1zjtgnwy.fsf@viffer.oslo.metis.no > @ 1999-02-28 22:53 ` Steinar Bang 1 sibling, 0 replies; 210+ messages in thread From: Steinar Bang @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs >>>>> 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-13 15:21 ` Jeffrey A Law [not found] ` < 13364.918948012@hurl.cygnus.com > 1999-02-14 4:39 ` egcs and linux Steinar Bang @ 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: Martin v. Loewis, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-13 15:16 ` H.J. Lu [not found] ` < m10BoHn-000392C@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: law, egcs > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de > 1999-02-13 15:16 ` H.J. Lu @ 1999-02-15 22:50 ` Jeffrey A Law [not found] ` < 20471.919147770@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-15 22:50 UTC (permalink / raw) To: Martin v. Loewis; +Cc: hjl, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 20471.919147770@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 20471.919147770@hurl.cygnus.com > @ 1999-02-16 0:39 ` Martin v. Loewis [not found] ` < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de > ` (3 more replies) 1999-02-16 6:57 ` H.J. Lu 1 sibling, 4 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-16 0:39 UTC (permalink / raw) To: law; +Cc: hjl, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de > @ 1999-02-16 0:45 ` Jeffrey A Law [not found] ` < 20770.919154653@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-16 0:45 UTC (permalink / raw) To: Martin v. Loewis; +Cc: hjl, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 20770.919154653@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 20770.919154653@hurl.cygnus.com > @ 1999-02-16 14:06 ` Martin v. Loewis 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 1 reply; 210+ messages in thread From: Martin v. Loewis @ 1999-02-16 14:06 UTC (permalink / raw) To: law; +Cc: hjl, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 14:06 ` Martin v. Loewis @ 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: hjl, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 0:45 ` Jeffrey A Law [not found] ` < 20770.919154653@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: hjl, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 0:39 ` Martin v. Loewis [not found] ` < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de > @ 1999-02-16 1:04 ` Steinar Bang 1999-02-28 22:53 ` Steinar Bang [not found] ` <20770.919154653.cygnus.egcs@hurl.cygnus.com> 1999-02-28 22:53 ` Martin v. Loewis 3 siblings, 1 reply; 210+ messages in thread From: Steinar Bang @ 1999-02-16 1:04 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 1:04 ` Steinar Bang @ 1999-02-28 22:53 ` Steinar Bang 0 siblings, 0 replies; 210+ messages in thread From: Steinar Bang @ 1999-02-28 22:53 UTC (permalink / raw) To: egcs >>>>> "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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: <20770.919154653.cygnus.egcs@hurl.cygnus.com>]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` <20770.919154653.cygnus.egcs@hurl.cygnus.com> @ 1999-02-16 10:47 ` Jason Merrill [not found] ` < u9yalyi3t6.fsf@yorick.cygnus.com > 1999-02-28 22:53 ` Jason Merrill 0 siblings, 2 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-16 10:47 UTC (permalink / raw) To: law; +Cc: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < u9yalyi3t6.fsf@yorick.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < u9yalyi3t6.fsf@yorick.cygnus.com > @ 1999-02-16 10:56 ` Joe Buck 1999-02-28 22:53 ` Joe Buck 1999-02-16 11:19 ` Jeffrey A Law 1 sibling, 1 reply; 210+ messages in thread From: Joe Buck @ 1999-02-16 10:56 UTC (permalink / raw) To: Jason Merrill; +Cc: law, egcs > 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). ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 10:56 ` Joe Buck @ 1999-02-28 22:53 ` Joe Buck 0 siblings, 0 replies; 210+ messages in thread From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill; +Cc: law, egcs > 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). ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < u9yalyi3t6.fsf@yorick.cygnus.com > 1999-02-16 10:56 ` Joe Buck @ 1999-02-16 11:19 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 1 reply; 210+ messages in thread From: Jeffrey A Law @ 1999-02-16 11:19 UTC (permalink / raw) To: Jason Merrill; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 11:19 ` Jeffrey A Law @ 1999-02-28 22:53 ` Jeffrey A Law 0 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill; +Cc: egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 10:47 ` Jason Merrill [not found] ` < u9yalyi3t6.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 1 sibling, 0 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 0:39 ` Martin v. Loewis ` (2 preceding siblings ...) [not found] ` <20770.919154653.cygnus.egcs@hurl.cygnus.com> @ 1999-02-28 22:53 ` Martin v. Loewis 3 siblings, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: hjl, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 20471.919147770@hurl.cygnus.com > 1999-02-16 0:39 ` Martin v. Loewis @ 1999-02-16 6:57 ` H.J. Lu 1999-02-28 22:53 ` H.J. Lu 1 sibling, 1 reply; 210+ messages in thread From: H.J. Lu @ 1999-02-16 6:57 UTC (permalink / raw) To: law; +Cc: martin, egcs > > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-16 6:57 ` H.J. Lu @ 1999-02-28 22:53 ` H.J. Lu 0 siblings, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: martin, egcs > > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-15 22:50 ` Jeffrey A Law [not found] ` < 20471.919147770@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: hjl, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-13 12:13 ` Martin v. Loewis [not found] ` < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de > @ 1999-02-28 22:53 ` Martin v. Loewis 1 sibling, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: hjl, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: <199902132010.VAA04139.cygnus.egcs@mira.isdn.cs.tu-berlin.de>]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` <199902132010.VAA04139.cygnus.egcs@mira.isdn.cs.tu-berlin.de> @ 1999-02-14 21:44 ` Jason Merrill [not found] ` < u9btiwjk5k.fsf@yorick.cygnus.com > 1999-02-28 22:53 ` Jason Merrill 0 siblings, 2 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-14 21:44 UTC (permalink / raw) To: Martin v. Loewis; +Cc: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < u9btiwjk5k.fsf@yorick.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < u9btiwjk5k.fsf@yorick.cygnus.com > @ 1999-02-15 17:43 ` H.J. Lu 1999-02-28 22:53 ` H.J. Lu 0 siblings, 1 reply; 210+ messages in thread From: H.J. Lu @ 1999-02-15 17:43 UTC (permalink / raw) To: Jason Merrill; +Cc: martin, egcs > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-15 17:43 ` H.J. Lu @ 1999-02-28 22:53 ` H.J. Lu 0 siblings, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Jason Merrill; +Cc: martin, egcs > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-14 21:44 ` Jason Merrill [not found] ` < u9btiwjk5k.fsf@yorick.cygnus.com > @ 1999-02-28 22:53 ` Jason Merrill 1 sibling, 0 replies; 210+ messages in thread From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: egcs >>>>> 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-13 11:26 ` Jeffrey A Law [not found] ` < 12451.918933918@hurl.cygnus.com > [not found] ` <199902132010.VAA04139.cygnus.egcs@mira.isdn.cs.tu-berlin.de> @ 1999-02-28 22:53 ` Jeffrey A Law 2 siblings, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu; +Cc: Martin v. Loewis, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-04 6:36 ` H.J. Lu [not found] ` < m108PtF-00038sC@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: law, egcs > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-02 14:22 ` Martin v. Loewis [not found] ` < 199902022216.XAA01250@mira.isdn.cs.tu-berlin.de > @ 1999-02-28 22:53 ` Martin v. Loewis 1 sibling, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: hjl; +Cc: law, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-02 7:12 ` H.J. Lu [not found] ` < m107hUo-000392C@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: law, egcs > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 199902012314.AAA00681@mira.isdn.cs.tu-berlin.de > 1999-02-02 7:12 ` H.J. Lu @ 1999-02-13 11:25 ` Jeffrey A Law [not found] ` < 12441.918933847@hurl.cygnus.com > 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 2 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-13 11:25 UTC (permalink / raw) To: Martin v. Loewis; +Cc: hjl, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < 12441.918933847@hurl.cygnus.com >]
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 [not found] ` < 12441.918933847@hurl.cygnus.com > @ 1999-02-13 12:08 ` Martin v. Loewis 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 1 reply; 210+ messages in thread From: Martin v. Loewis @ 1999-02-13 12:08 UTC (permalink / raw) To: law; +Cc: hjl, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-13 12:08 ` Martin v. Loewis @ 1999-02-28 22:53 ` Martin v. Loewis 0 siblings, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: law; +Cc: hjl, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-13 11:25 ` Jeffrey A Law [not found] ` < 12441.918933847@hurl.cygnus.com > @ 1999-02-28 22:53 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: hjl, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-01 15:22 ` Martin v. Loewis [not found] ` < 199902012314.AAA00681@mira.isdn.cs.tu-berlin.de > @ 1999-02-28 22:53 ` Martin v. Loewis 1 sibling, 0 replies; 210+ messages in thread From: Martin v. Loewis @ 1999-02-28 22:53 UTC (permalink / raw) To: hjl; +Cc: law, egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-01 7:02 ` H.J. Lu [not found] ` < m107Krt-00038sC@ocean.lucon.org > @ 1999-02-28 22:53 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-02-28 22:53 UTC (permalink / raw) To: Martin v. Loewis; +Cc: law, egcs > > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* RE: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-31 9:28 ` H.J. Lu 1999-01-31 23:58 ` Martin v. Loewis @ 1999-02-01 7:03 ` James Mansion 1999-02-28 22:53 ` James Mansion 1 sibling, 1 reply; 210+ messages in thread From: James Mansion @ 1999-02-01 7:03 UTC (permalink / raw) To: H.J. Lu, law; +Cc: egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* RE: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-02-01 7:03 ` James Mansion @ 1999-02-28 22:53 ` James Mansion 0 siblings, 0 replies; 210+ messages in thread From: James Mansion @ 1999-02-28 22:53 UTC (permalink / raw) To: H.J. Lu, law; +Cc: egcs > 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-30 18:38 ` Jeffrey A Law 1999-01-31 9:28 ` H.J. Lu @ 1999-01-31 23:58 ` Jeffrey A Law 1 sibling, 0 replies; 210+ messages in thread From: Jeffrey A Law @ 1999-01-31 23:58 UTC (permalink / raw) To: H.J. Lu; +Cc: Alexandre Oliva, jason, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-30 13:44 ` H.J. Lu 1999-01-30 18:38 ` Jeffrey A Law @ 1999-01-31 23:58 ` H.J. Lu 1 sibling, 0 replies; 210+ messages in thread From: H.J. Lu @ 1999-01-31 23:58 UTC (permalink / raw) To: Alexandre Oliva; +Cc: jason, egcs > > 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) ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1 1999-01-30 12:51 ` Alexandre Oliva 1999-01-30 13:44 ` H.J. Lu @ 1999-01-31 23:58 ` Alexandre Oliva 1 sibling, 0 replies; 210+ messages in thread From: Alexandre Oliva @ 1999-01-31 23:58 UTC (permalink / raw) To: H.J. Lu, jason; +Cc: sb, egcs 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 ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux @ 1999-02-16 18:32 N8TM [not found] ` < ce4a0e3a.36ca2909@aol.com > 1999-02-28 22:53 ` N8TM 0 siblings, 2 replies; 210+ messages in thread From: N8TM @ 1999-02-16 18:32 UTC (permalink / raw) To: jbuck, hjl; +Cc: sb, egcs 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
[parent not found: < ce4a0e3a.36ca2909@aol.com >]
* Re: egcs and linux [not found] ` < ce4a0e3a.36ca2909@aol.com > @ 1999-02-16 18:35 ` Joe Buck 1999-02-28 22:53 ` Joe Buck 0 siblings, 1 reply; 210+ messages in thread From: Joe Buck @ 1999-02-16 18:35 UTC (permalink / raw) To: N8TM; +Cc: jbuck, hjl, sb, egcs > << 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-16 18:35 ` Joe Buck @ 1999-02-28 22:53 ` Joe Buck 0 siblings, 0 replies; 210+ messages in thread From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw) To: N8TM; +Cc: jbuck, hjl, sb, egcs > << 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
* Re: egcs and linux 1999-02-16 18:32 egcs and linux N8TM [not found] ` < ce4a0e3a.36ca2909@aol.com > @ 1999-02-28 22:53 ` N8TM 1 sibling, 0 replies; 210+ messages in thread From: N8TM @ 1999-02-28 22:53 UTC (permalink / raw) To: jbuck, hjl; +Cc: sb, egcs 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. ^ permalink raw reply [flat|nested] 210+ messages in thread
end of thread, other threads:[~1999-02-28 22:53 UTC | newest] Thread overview: 210+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-01-29 17:26 multiple definitions of 'xxx keyed to...' in egcs-1.1.1 H.J. Lu 1999-01-30 12:51 ` Alexandre Oliva 1999-01-30 13:44 ` H.J. Lu 1999-01-30 18:38 ` Jeffrey A Law 1999-01-31 9:28 ` H.J. Lu 1999-01-31 23:58 ` Martin v. Loewis 1999-02-01 7:02 ` H.J. Lu [not found] ` < m107Krt-00038sC@ocean.lucon.org > 1999-02-01 15:22 ` Martin v. Loewis [not found] ` < 199902012314.AAA00681@mira.isdn.cs.tu-berlin.de > 1999-02-02 7:12 ` H.J. Lu [not found] ` < m107hUo-000392C@ocean.lucon.org > 1999-02-02 14:22 ` Martin v. Loewis [not found] ` < 199902022216.XAA01250@mira.isdn.cs.tu-berlin.de > 1999-02-04 6:36 ` H.J. Lu [not found] ` < m108PtF-00038sC@ocean.lucon.org > 1999-02-13 11:26 ` Jeffrey A Law [not found] ` < 12451.918933918@hurl.cygnus.com > 1999-02-13 12:13 ` Martin v. Loewis [not found] ` < 199902132010.VAA04139@mira.isdn.cs.tu-berlin.de > 1999-02-13 15:16 ` H.J. Lu [not found] ` < m10BoHn-000392C@ocean.lucon.org > 1999-02-13 15:21 ` Jeffrey A Law [not found] ` < 13364.918948012@hurl.cygnus.com > 1999-02-13 15:41 ` H.J. Lu [not found] ` < m10Boh4-000392C@ocean.lucon.org > 1999-02-13 21:42 ` Jeffrey A Law [not found] ` < 13959.918970867@hurl.cygnus.com > 1999-02-15 17:00 ` H.J. Lu [not found] ` < m10CYsJ-00038sC@ocean.lucon.org > 1999-02-15 17:46 ` Mark Mitchell [not found] ` < 199902160149.RAA28975@adsl-206-170-148-33.dsl.pacbell.net > 1999-02-15 17:50 ` H.J. Lu [not found] ` < m10CZeU-00038sC@ocean.lucon.org > 1999-02-15 18:10 ` Mark Mitchell [not found] ` < 199902160212.SAA29229@adsl-206-170-148-33.dsl.pacbell.net > 1999-02-17 13:39 ` Kamil Iskra [not found] ` < Pine.LNX.3.96.990217221633.1697A-100000@jinks.home > 1999-02-17 13:45 ` Zack Weinberg 1999-02-28 22:53 ` Zack Weinberg 1999-02-28 22:53 ` Kamil Iskra 1999-02-28 22:53 ` Mark Mitchell [not found] ` <199902160212.SAA29229.cygnus.egcs@adsl-206-170-148-33.dsl.pacbell.net> 1999-02-16 10:51 ` Jason Merrill [not found] ` < u9ww1ii3mw.fsf@yorick.cygnus.com > 1999-02-16 11:29 ` Mark Mitchell 1999-02-17 0:26 ` Steinar Bang 1999-02-28 22:53 ` Steinar Bang 1999-02-28 22:53 ` Mark Mitchell 1999-02-16 23:23 ` Jeffrey A Law 1999-02-16 23:33 ` Jason Merrill [not found] ` < u9iud1iiwm.fsf@yorick.cygnus.com > 1999-02-17 6:49 ` H.J. Lu [not found] ` < m10D8I7-00038sC@ocean.lucon.org > 1999-02-17 11:45 ` Jeffrey A Law 1999-02-17 12:38 ` Jason Merrill [not found] ` < u990dwix4w.fsf@yorick.cygnus.com > 1999-02-18 6:42 ` H.J. Lu [not found] ` < m10DUeS-00038sC@ocean.lucon.org > 1999-02-20 12:47 ` Jeffrey A Law [not found] ` < 4798.919543586@hurl.cygnus.com > 1999-02-20 12:55 ` H.J. Lu [not found] ` < m10EJQj-000392C@ocean.lucon.org > 1999-02-20 12:58 ` Jeffrey A Law [not found] ` < 4881.919544286@hurl.cygnus.com > 1999-02-20 13:02 ` H.J. Lu [not found] ` < m10EJXX-000392C@ocean.lucon.org > 1999-02-20 13:09 ` Jeffrey A Law [not found] ` < 4941.919544939@hurl.cygnus.com > 1999-02-20 13:12 ` H.J. Lu 1999-02-28 22:53 ` Jeffrey A Law 1999-02-20 13:33 ` Robert Lipe [not found] ` < 19990220153254.A8783@rjlhome.sco.com > 1999-02-20 14:36 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Robert Lipe 1999-02-28 22:53 ` H.J. Lu 1999-02-22 0:46 ` Andris Pavenis 1999-02-28 22:53 ` Andris Pavenis 1999-02-28 22:53 ` Jeffrey A Law 1999-02-20 13:17 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-20 13:34 ` Mumit Khan 1999-02-28 22:53 ` Mumit Khan 1999-02-20 15:35 ` Martin v. Loewis [not found] ` < 199902202335.AAA06542@mira.isdn.cs.tu-berlin.de > 1999-02-20 16:11 ` H.J. Lu [not found] ` < m10EMUB-000392C@ocean.lucon.org > 1999-02-21 15:15 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Martin v. Loewis 1999-02-21 13:59 ` Jason Merrill [not found] ` < u9vhgvfmfa.fsf@yorick.cygnus.com > 1999-02-21 15:22 ` Jeffrey A Law [not found] ` < 7817.919639310@hurl.cygnus.com > 1999-02-21 15:28 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-21 16:16 ` Jason Merrill [not found] ` < u9lnhrfg3k.fsf@yorick.cygnus.com > 1999-02-21 16:40 ` Jeffrey A Law [not found] ` < 8103.919644009@hurl.cygnus.com > 1999-02-21 17:07 ` Richard Henderson [not found] ` < 19990221170738.A22156@cygnus.com > 1999-02-21 17:16 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Richard Henderson 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` H.J. Lu 1999-02-20 12:58 ` Zack Weinberg [not found] ` < 199902202057.PAA22565@blastula.phys.columbia.edu > 1999-02-20 13:28 ` Jeffrey A Law [not found] ` < 5066.919546022@hurl.cygnus.com > 1999-02-20 13:35 ` Zack Weinberg [not found] ` < 199902202135.QAA23017@blastula.phys.columbia.edu > 1999-02-20 13:42 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-20 15:40 ` Martin v. Loewis [not found] ` < 199902202338.AAA06546@mira.isdn.cs.tu-berlin.de > 1999-02-21 3:45 ` Kamil Iskra [not found] ` < Pine.LNX.3.96.990221120241.903C-100000@jinks.home > 1999-02-21 11:20 ` Martin v. Loewis 1999-02-28 22:53 ` Martin v. Loewis 1999-02-28 22:53 ` Kamil Iskra 1999-02-28 22:53 ` Martin v. Loewis 1999-02-28 22:53 ` Zack Weinberg 1999-02-21 18:22 ` the jackal [not found] ` < 19990221211950.B10271@diwanh.stu.rpi.edu > 1999-02-21 18:47 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` the jackal 1999-02-28 22:53 ` Jeffrey A Law 1999-02-22 0:40 ` Andris Pavenis [not found] ` < 99022210384700.00200@hal > 1999-02-22 6:59 ` H.J. Lu 1999-02-24 0:18 ` Andris Pavenis 1999-02-28 22:53 ` Andris Pavenis 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Andris Pavenis 1999-02-28 22:53 ` Zack Weinberg 1999-02-20 12:58 ` H.J. Lu [not found] ` < m10EJTY-000392C@ocean.lucon.org > 1999-02-20 13:04 ` Jeffrey A Law [not found] ` < 4923.919544645@hurl.cygnus.com > 1999-02-20 13:15 ` H.J. Lu [not found] ` < m10EJjp-000392C@ocean.lucon.org > 1999-02-20 15:40 ` Martin v. Loewis 1999-02-28 22:53 ` Martin v. Loewis 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Jason Merrill [not found] ` < 26163.919280679@hurl.cygnus.com > 1999-02-17 15:45 ` Martin v. Loewis [not found] ` < 199902172339.AAA01000@mira.isdn.cs.tu-berlin.de > 1999-02-17 15:48 ` Jeffrey A Law [not found] ` < 26749.919295221@hurl.cygnus.com > 1999-02-17 16:37 ` Martin v. Loewis 1999-02-28 22:53 ` Martin v. Loewis 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Martin v. Loewis 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` H.J. Lu 1999-02-21 20:30 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Mark Mitchell 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` H.J. Lu 1999-02-14 4:39 ` egcs and linux Steinar Bang [not found] ` < wh1zjtgnwy.fsf@viffer.oslo.metis.no > 1999-02-14 7:06 ` Marc Espie 1999-02-14 7:23 ` Steinar Bang [not found] ` < whogmxdn6i.fsf@viffer.oslo.metis.no > 1999-02-14 8:01 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Steinar Bang 1999-02-28 22:53 ` Marc Espie 1999-02-14 8:00 ` Jeffrey A Law 1999-02-14 8:05 ` Steinar Bang [not found] ` < whemntdl8m.fsf@viffer.oslo.metis.no > 1999-02-14 8:10 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Steinar Bang 1999-02-28 22:53 ` Jeffrey A Law 1999-02-14 9:39 ` Scott McDermott 1999-02-14 10:00 ` Steinar Bang 1999-02-28 22:53 ` Steinar Bang 1999-02-28 22:53 ` Scott McDermott 1999-02-14 22:47 ` Joe Buck [not found] ` < 199902150645.WAA17085@atrus.synopsys.com > 1999-02-15 17:40 ` H.J. Lu [not found] ` < m10CZUe-00038sC@ocean.lucon.org > 1999-02-16 9:58 ` Joe Buck [not found] ` < 199902161756.JAA18794@atrus.synopsys.com > 1999-02-16 20:13 ` H.J. Lu 1999-02-16 20:55 ` Scott Bambrough 1999-02-28 22:53 ` Scott Bambrough 1999-02-28 22:53 ` H.J. Lu 1999-02-18 15:37 ` Horst von Brand 1999-02-28 22:53 ` Horst von Brand 1999-02-28 22:53 ` Joe Buck 1999-02-16 10:06 ` Joe Buck [not found] ` < 199902161805.KAA18983@atrus.synopsys.com > 1999-02-16 20:02 ` H.J. Lu 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Joe Buck 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Joe Buck 1999-02-28 22:53 ` Steinar Bang 1999-02-28 22:53 ` multiple definitions of 'xxx keyed to...' in egcs-1.1.1 Jeffrey A Law 1999-02-28 22:53 ` H.J. Lu 1999-02-15 22:50 ` Jeffrey A Law [not found] ` < 20471.919147770@hurl.cygnus.com > 1999-02-16 0:39 ` Martin v. Loewis [not found] ` < 199902160838.JAA00531@mira.isdn.cs.tu-berlin.de > 1999-02-16 0:45 ` Jeffrey A Law [not found] ` < 20770.919154653@hurl.cygnus.com > 1999-02-16 14:06 ` Martin v. Loewis 1999-02-28 22:53 ` Martin v. Loewis 1999-02-28 22:53 ` Jeffrey A Law 1999-02-16 1:04 ` Steinar Bang 1999-02-28 22:53 ` Steinar Bang [not found] ` <20770.919154653.cygnus.egcs@hurl.cygnus.com> 1999-02-16 10:47 ` Jason Merrill [not found] ` < u9yalyi3t6.fsf@yorick.cygnus.com > 1999-02-16 10:56 ` Joe Buck 1999-02-28 22:53 ` Joe Buck 1999-02-16 11:19 ` Jeffrey A Law 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Martin v. Loewis 1999-02-16 6:57 ` H.J. Lu 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Martin v. Loewis [not found] ` <199902132010.VAA04139.cygnus.egcs@mira.isdn.cs.tu-berlin.de> 1999-02-14 21:44 ` Jason Merrill [not found] ` < u9btiwjk5k.fsf@yorick.cygnus.com > 1999-02-15 17:43 ` H.J. Lu 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Jason Merrill 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` H.J. Lu 1999-02-28 22:53 ` Martin v. Loewis 1999-02-28 22:53 ` H.J. Lu 1999-02-13 11:25 ` Jeffrey A Law [not found] ` < 12441.918933847@hurl.cygnus.com > 1999-02-13 12:08 ` Martin v. Loewis 1999-02-28 22:53 ` Martin v. Loewis 1999-02-28 22:53 ` Jeffrey A Law 1999-02-28 22:53 ` Martin v. Loewis 1999-02-28 22:53 ` H.J. Lu 1999-02-01 7:03 ` James Mansion 1999-02-28 22:53 ` James Mansion 1999-01-31 23:58 ` Jeffrey A Law 1999-01-31 23:58 ` H.J. Lu 1999-01-31 23:58 ` Alexandre Oliva 1999-02-16 18:32 egcs and linux N8TM [not found] ` < ce4a0e3a.36ca2909@aol.com > 1999-02-16 18:35 ` Joe Buck 1999-02-28 22:53 ` Joe Buck 1999-02-28 22:53 ` N8TM
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).