This is the mail archive of the gdb@sources.redhat.com 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]

RFC: Components


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

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