Re: libgdb.a

[Andris Pavenis <andris@stargate.astr.lu.lv>]

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