Re: [Linux-ia64] Re: gdb null ptr

[David B Anderson <davea@quasar.engr.sgi.com>]

Jim Blandy <jimb@cygnus.com> writes:
>It was the SGI Fortran 90 compiler.  I haven't seen any reports of similar
>problems with the SGI C or C++ compilers.

Um. Yes.  And I'm trying to pull together a description of
the f90 name mangling going on there.
Only just started on that a day or so ago and have  not had
much time to look at it.

F90 is using DW_AT_common and name mangling to describe
modules and things and, well, I've not found any
nice description of what-is-going-on/how-f90-is-using-dwarf. Yet.

Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/
From davea@quasar.engr.sgi.com Thu Nov 09 14:21:00 2000
From: David B Anderson <davea@quasar.engr.sgi.com>
To: gdb@sources.redhat.com
Subject: Re: pathmap or dir command on drugs
Date: Thu, 09 Nov 2000 14:21:00 -0000
Message-id: <200011092219.OAA22623@quasar.engr.sgi.com>
X-SW-Source: 2000-11/msg00049.html
Content-length: 1724

    > As for dbx, I suggest to give numbers to each pathmap so that deletion is
    > made on the index rather than on some path.

David Taylor <taylor@cygnus.com writes:
>When I last used dbx it didn't have a pathmap command.  And my current
>system doesn't have dbx on it -- would you be willing to summarize the
>current dbx pathmap command?

Sun dbx started this thread. 
SGI dbx has a pathmap facility also (has had for a long time).

I'll describe it, but am not promoting it as desirable syntax!

============
Background, directory paths:
	use <dir1> <dir2>
replaces the current list of search paths with dir1,dir2.
	example:  use /abc /def

	use
print the list of directory paths

	dir <dir1>
adds dir1 to the list of search paths (at the end of the list).


============
pathmap:

dir  /a/b/c/:/hosts/foo/

adds a special entry to the list of search paths.
pathmap entries show up in the 'use' list
just like regular directory-path entries.

If the literal
	/a/b/c/
is found in a path then it is replaced by /hosts/foo/
from the pathmap
and no further pathmapping is done (only one replacement).

The pathmaps and directories are in a single list but
are actually searched in separate loops.
(sequential search: not a problem in practice).

One drawback is that a : in a path cannot
be represented in the directory
search list (has not been a problem in practice, fortunately).

It's worked really well
for the cases already mentioned in this thread:

   A source tree has moved from /a/b/c to /d/e/f/xold
	dir /a/b/c/:/d/e/f/xold/

   A source tree is remote, so use the automounter
		dir /a/:/hosts/somemachine.domain/a/



Regards,
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/
From jtc@redback.com Thu Nov 09 14:35:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Rudy Folden <rfolden@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: libremote activation
Date: Thu, 09 Nov 2000 14:35:00 -0000
Message-id: <5mu29gdb97.fsf@jtc.redback.com>
References: <3A0B0F63.254C569A@redhat.com>
X-SW-Source: 2000-11/msg00050.html
Content-length: 1606

>>>>> "Rudy" == Rudy Folden <rfolden@redhat.com> writes:
Rudy> Michael Snyder and I are working on what we believe to be the
Rudy> first native version of libremote for an embedded Linux system.

Thanks for the explanation of what libremote is.  Note that I make the
following suggestions knowing pretty much nothing about it.

* If GDB, or the remote protocol, needs to be changed in any way to
  support automatic activation of libremote, there needs to be more
  disclosure about what it is.  Even if it's kept redhat proprietary,
  we'll need a spec so we can properly interface with it.

* Your comments about starting libremote via an inetd like mechanism
  vs. starting it at runtime seem somewhat contradictory.  Yes, many
  embedded systems have little memory, but the footprint of a debug
  agent should be very small (10-20K).  If you have room to run an
  inetd like program, you should be able to run a debug agent as well.
  Note, if inetd is spawning the program, it's going to take the same
  amount of memory as if it was spawned at system startup.

* Your comments about libremote stopping after GDB exits and needing
  an instance for each program under debug are manifestations of
  design bugs in the remote protocol.  A single debug agent should be
  able to be started at system bringup; support debugging any number
  of processes (and any number of threads); and should not exit when
  GDB quits.  In order for the debug agent not to have to manage
  multiple communication channels, that might be handled by a host-
  side proxy.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From fnasser@cygnus.com Thu Nov 09 15:38:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb@sources.redhat.com
Subject: RFC: Components
Date: Thu, 09 Nov 2000 15:38:00 -0000
Message-id: <3A0B3556.510B850A@cygnus.com>
X-SW-Source: 2000-11/msg00051.html
Content-length: 4208

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
From bstell@netscape.com Thu Nov 09 16:59:00 2000
From: bstell@netscape.com (Brian Stell)
To: gdb_mailing_list <gdb@sources.redhat.com>
Subject: extending Gdb to display app specific data
Date: Thu, 09 Nov 2000 16:59:00 -0000
Message-id: <3A0B4885.B2384AE7@netscape.com>
X-SW-Source: 2000-11/msg00052.html
Content-length: 1051

Has there been a thread on how to extend Gdb
to display app specific data?

The reason I ask is as more apps support Unicode
it is hard for the developers to see the text in strings
since the strings are no longer simple "char *".

The strings could be UTF-8, UTF-16, some kind
of C++ object, etc.

What provision is there for Gdb users to extend
Gdb to display an application specific item like
this?

This, of course, is a particular instance of the
need to display various types of app. specific
data which out the user having to type in a
long or complex routine each time. It is fine to
require that the routines be complex as a few
developers will figure out how to do it and the
rest will copy the answer and benefit.


Brian,

PS: I asked the Insight mailing list the same
question and they suggested I as gdb:

> Fernando Nasser wrote:
> You should ask first if there are plans for GDB (gdb@sources.redhat.com) to
> handle/display Unicode data.   Insight, being the GDB GUI, will probably
> follow with some way to access what GDB provides.