Re: RFC: Components

[Andrew Cagney <ac131313 at cygnus dot com>]

Fernando Nasser wrote:
> 
> We got a submission from a contributor that would like to add the following
> facility to GDB, which can be useful when debugging Operating Systems.
> 
>         An operating system can comprise of several components, each of them
>         linked separately. When doing system debug, the symbols of all the
>         OS components are loaded into GDB. Once loaded, GDB has several symbol
>         files that it uses to search for symbols and debugging information.

(Like J.T. I'm not also sure about the word component)

I think this can be broken down into several problems/issues.


GDB is (eventually :-) going to get support for multiple
processes/actors/....  Such proceses can probably be categorized into
two classes:

	o	VM

		Where separate processes have
		independant address spaces.

		Examples include most modern
		OS's along with UNIX and Linux.

	o	no-vm

		Where separate processes share
		a common address space.

		Examples of this would include
		uLinux and MINIX/68k.

I think an extention to GDB's SAL (linespec) syntax needs to be clearly
defined so that it will be possible to identify the process that a
symbol belongs to.  The exact syntax will likely need more thought
although the proposal is probably a good starting point.  It is more
natural to use the target OS's process names and that is a departure
from the current GDB convention which, in the case of threads, adopted
arbitrary internal numbers.


Depending on the kernel, it may be possible to unwind a stack back
through the user->kernel system call.  On such systems, the stack dump
should clearly identify the process that the stack frames belong to.  On
OSs that use an indirect call to get into the kernel, this is pretty
much a no-brainer.  On OSs that context switch on entry into the kernel,
this is more complex  Something a bit like the code to unwind past a
single handler would be needed.


At a more general level, I don't have any real reservations about the
proposed functionality (I've encountered a number of embedded systems
where I've had to use smoke and mirrors to get around just this
problem).  The concerns I have are related to the details of the
implementation and how well the actual changes fit in with the broad
strategy of evolving GDB into a multi-processor debugger.

	Andrew