Re: RFC: Components

[Stephane Carrez <Stephane dot Carrez at worldnet dot fr>]

Hi!

Andrew Cagney a écrit :
> 
> 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)

So do I. But I had no better name to propose/use...


> 
> 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.

Yes, but using the target OS's process name is more difficult. The so-called
component may not refer to a process. It can of course, but it can also
represent some code that is loaded.

Doing that requires more changes in Gdb too, since this is target specific.
We also need a way to attach some target specific name to the symtab.


> 
> 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.

Stack unwinding does not work in gdb when you cross a trap/exception handler
It would be good to teach that in Gdb. But it's not easy...


> 
> 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

Using the basename of the symbol file was very simple. I guess it's possible
to use another transformation operation that produces such short printable string.


	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France