From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andris Pavenis To: Andrew Cagney , gdb-patches@cygnus.com Subject: Re: libgdb.a Date: Thu, 01 Apr 1999 00:00:00 -0000 Message-id: <99031110271800.05108@hal> References: <36E70EE3.3D0937F1@cygnus.com> X-SW-Source: 1999-q1/msg00082.html On Thu, 11 Mar 1999, Andrew Cagney wrote: >Andris Pavenis wrote: > >> Maybe it would be usefull to implement init functions of higher priority that >> are executed before ones which names begins with _initialize_. >> So we would be able to avoid gcc related extensions such as >> __attribute__((constructor)). >> >> For that we should use a different name prefix (eg. _preinit_ or something like) >> and require that these functions are independent one from another one (should >> not use results of other similar init functions). > >This has been discussed before (but on another list) and on the last occasion it >was actually me suggested something along similar lines to your proposal. I lost >the the discussion :-) > >The consensus was that if GDB started down the path of having two initialization >levels it could quickly find itself heading for a situtation where there were N >initialization levels and a really confused startup sequence. It was thought that, >if anything, we should be trying to discourage additional complexity being >introduced during startup. > >As an example, consider the idea (that was recently floated) of GDB suporting >several target-architectures. Instead of fully initializing the code for all the >target-architectures during startup, it would probably be more prudent to leave >most of that task until the point where GDB knew exactly which architecture was >being debugged. > Yes I agree that introducing more initialization levels maybe not acceptable. Anyway if we should change interface for libgdb.a then it's best do do it now in such way we probably won't need to do it again soon (Introducing typedef GDB_FILE is already such change) . I suggest follwing: 1) move definitions of such variables to separate file out of main.c 2) move initialization of these variables to the same file and create procedure that initializes tham. 3) call this newly introduced procedure from very begin of main As the result we'll be able to place newly introduced file in libgdb.a. Perhaps it would be best to add some C preprocessor macro so programs that uses libgdb.a could found that at compile time. So we could move such initialization to a separate file that could be included in libgdb.a. Of course programs that uses libgdb.a will have to call init function at first. Andris PS. I'm not subscribed to this list. So please CC: answer to me From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andris Pavenis To: Andrew Cagney , gdb-patches@cygnus.com Subject: Re: libgdb.a Date: Thu, 11 Mar 1999 00:27:00 -0000 Message-ID: <99031110271800.05108@hal> References: <36E70EE3.3D0937F1@cygnus.com> X-SW-Source: 1999-03/msg00028.html Message-ID: <19990311002700.WRroBiq_1MIVfzAlC8DZhpEKsAC_VYsCizRzP6eOiIY@z> On Thu, 11 Mar 1999, Andrew Cagney wrote: >Andris Pavenis wrote: > >> Maybe it would be usefull to implement init functions of higher priority that >> are executed before ones which names begins with _initialize_. >> So we would be able to avoid gcc related extensions such as >> __attribute__((constructor)). >> >> For that we should use a different name prefix (eg. _preinit_ or something like) >> and require that these functions are independent one from another one (should >> not use results of other similar init functions). > >This has been discussed before (but on another list) and on the last occasion it >was actually me suggested something along similar lines to your proposal. I lost >the the discussion :-) > >The consensus was that if GDB started down the path of having two initialization >levels it could quickly find itself heading for a situtation where there were N >initialization levels and a really confused startup sequence. It was thought that, >if anything, we should be trying to discourage additional complexity being >introduced during startup. > >As an example, consider the idea (that was recently floated) of GDB suporting >several target-architectures. Instead of fully initializing the code for all the >target-architectures during startup, it would probably be more prudent to leave >most of that task until the point where GDB knew exactly which architecture was >being debugged. > Yes I agree that introducing more initialization levels maybe not acceptable. Anyway if we should change interface for libgdb.a then it's best do do it now in such way we probably won't need to do it again soon (Introducing typedef GDB_FILE is already such change) . I suggest follwing: 1) move definitions of such variables to separate file out of main.c 2) move initialization of these variables to the same file and create procedure that initializes tham. 3) call this newly introduced procedure from very begin of main As the result we'll be able to place newly introduced file in libgdb.a. Perhaps it would be best to add some C preprocessor macro so programs that uses libgdb.a could found that at compile time. So we could move such initialization to a separate file that could be included in libgdb.a. Of course programs that uses libgdb.a will have to call init function at first. Andris PS. I'm not subscribed to this list. So please CC: answer to me