This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RFC: Components
- To: gdb at sources dot redhat dot com
- Subject: RFC: Components
- From: Fernando Nasser <fnasser at cygnus dot com>
- Date: Thu, 09 Nov 2000 23:37:58 +0000
- Organization: Red Hat Canada Ltd. - Toronto
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.
Because these components are linked independently, it is possible to
have a symbol with the same name in different components. Currently,
GDB can use the filename to distinguish between two equally named
global symbols.
However, the source file can be the same because several components
can share the same libraries. Addresses, however, may not be the same
because if the components are loaded in the same address space
(supervisor mode), they will have different start addresses.
This means that specification of the component becomes necessary for
debugging:
- In the stack backtrace ('where' command), it is necessary to know
the name of the component the symbol belongs to. Indication
of the source file is useless because it can be the same for
two different components. Knowing the name of the component
is important to know when one component calls another one.
- In the report of a symbol (disassembly for example), knowing
the name of the component is also necessary as to make sure
we are looking at the symbol of the right component.
- When setting a breakpoint, the specification of the
component helps in being sure the breakpoint is set at the
right address. In 90% of cases, GDB has a default behavior
that uses the wrong component.
To solve these problems, I have made the following enhancements :
o The component name is printed before the name of the
symbol. The component name corresponds to the basename of
the symbol file without extension (if any).
This is controlled by a new GDB variable that can be set
with the 'set print component' (default is cleared, current
behavior).
The result looks like:
0x49e8a0 <kern:printf>: stwu r1,-128(r1)
o Parsing an expression is improved to identify a specific
symbol file based on the component name. The parsing affects
all GDB commands which are based on the 'decode_line_x'
functions as well as GDB computation of C expressions.
An existing syntax format was used:
<component>:<symbol>
The example below illustrates the problem with two components
'kern' and 'N_iom'. Both of them define the symbol 'printf'
(same source file). These two symbols are in fact at two different
addresses:
(chgdb) x/10i kern:printf
0x49e8a0 <kern:printf>: stwu r1,-128(r1)
(chgdb) x/10i N_iom:printf
0xa00dafc4 <N_iom:printf>: stwu r1,-128(r1)
The gdb control 'set print symbol-filename' is useless in this
situation because it reports exactly the same source file:
(chgdb) x/i kern:printf
0x49e8a0 <kern:printf at
/export/home2/ciceron/ppc-debug/build-NUCLEUS/src/lib/libc/consio/consPrin
tf.c:3
5>: stwu r1,-128(r1)
(chgdb) x/i N_iom:printf
0xa00dafc4 <N_iom:printf at
/export/home2/ciceron/ppc-debug/build-NUCLEUS/src/lib/libc/consio/consPrin
tf.c:3
5>: stwu r1,-128(r1)
Setting a breakpoint works as expected:
(chgdb) b kern:printf
Breakpoint 1 at 0x49e8f8: file
/export/home2/ciceron/ppc-debug/build-NUCLEUS/src/lib/libc/consio/consPrin
tf.c,
line 39.
(chgdb) b N_iom:printf
Breakpoint 2 at 0xa00db01c: file
/export/home2/ciceron/ppc-debug/build-NUCLEUS/src/lib/libc/consio/consPrin
tf.c,
line 39.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9