This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 11/18] Add partition support.


>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> +/* We need to keep the symbols in each PD separate from the others.
Joel> +   One of the reasons is that 2 symbols with the same name are allowed to
Joel> +   coexist in 653 provided that these 2 symbols live in 2 separate PDs.
Joel> +   Another important reason is that virtual memory regions can overlap
Joel> +   between PDs, and one symbol address in a PD is not suitable in the
Joel> +   context of another PD.
Joel> +   
Joel> +   GDB maintains a global list of objfiles where the symbols can be found.
Joel> +   To achieve this separation, we simply maintain one such list per PD in
Joel> +   this module.  At each PD change, we simply save the objfile list for
Joel> +   the current PD, and restore it for the new PD.  The net effect is that
Joel> +   GDB will only recognize symbols in the current PD, and will complain if
Joel> +   a user tries to do any operation that needs symbols from other PDs.
Joel> +
Joel> +   In practice, GDB maintains a few other global variables that also
Joel> +   need to be saved/restored, but the principle remains valid.
Joel> +   
Joel> +   If would have been slicker to actually maintain one list of objfiles
Joel> +   for all PDs and modify GDB to automatically switch to the right PD
Joel> +   when performing an operation such as inserting a BP in some code that's
Joel> +   in a different partition.  This would probably not be such a great
Joel> +   improvment in terms of usability, but this would require a major

Typo, "improvement".  Thanks, Emacs!

More importantly, why can't a PD be modeled using program- and
address-spaces inside GDB?

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]