This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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.
enjoy,
Andrew