This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Components
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: RFC: Components
- From: Stephane Carrez <Stephane dot Carrez at worldnet dot fr>
- Date: Tue, 21 Nov 2000 00:46:58 +0100
- CC: Fernando Nasser <fnasser at cygnus dot com>, gdb at sources dot redhat dot com
- References: <3A0B3556.510B850A@cygnus.com> <3A19491E.E2FDB7FB@cygnus.com>
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