Problem about insight rename patch
Andrew Cagney
ac131313@redhat.com
Mon Oct 21 12:08:00 GMT 2002
>> Basically removing
>> _initialize_gdbtk from init.c
>> does not prevent gdb from compiling,
>> so the only reason why I didn't send a patch proposal
>> is that I don't know the correct way of fixing it?
>> Maybe separate init.c
>> into init.c and insight-init.c?
>> But there might be better solutions?
>
>
> I believe the proper way to do this (Andrew/others will step in and tell
> me if I'm barking up the wrong perverbial tree) is to create an
> init_chain, which holds callbacks to be made for initialization.
> insight-main.c could register _initialize_gdbtk to this chain and top.c
> would then call it when it was doing initializations. My initial plan was
> to submit a patch to do just this. Eventually we could investigate getting
> other initializations registered in main (or we could simple keep init.c).
>
> Or we could just create a new initialize_hook (yich) which main could set
> to get _initialize_gdbtk to run. Or we could just integrate
> _initialize_gdbtk into main(), or ...
Any / all of the above.
Similar issues arise with MI, TUI and CLI. The way init.c is created
could do with a re-think. Fortunatly it isn't causing any immediate pain.
One thing though, I think more of the files should always be added to
libgdb.a. I can't think of a reason for not including MI or CLI files
in the archive by default.
Andrew
More information about the Gdb-patches
mailing list