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

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

[Daniel Berlin]

Kevin Buettner <kevinb@cygnus.com> writes:

> 
> Nice analysis.
> 
> The patch below effectively implements Jim's suggestion #2 above. 
> This patch was made with respect to sourceware and might not apply
> cleanly to sources from which the current linux/ia64 gdb is being
> built.  (I can provide such patches if desired however.)
> 
> I've tested it against the program provided by Pete Wyckoff and
> it does fix the segfault.
> 
> I will leave it to the dwarf2 maintainers to decide whether this
> patch is acceptable or if it would be better to implement one of
> Jim's other suggestions.
> 

Unfortuantely , this is actually still wrong for languages other than
C++, because we don't have the same guarantees about uniqueness in the name.

I was actually in the process of readying patches that add the same
type of name based caching (based on mangled name) to partial and
normal symbol reading, which gives us an amazing win for C++.

These patches also moved all of the name caching into "if (cu_language
== language_cplus)" blocks, doing what we used to do in the old case
(IE no caching).

Rather than let this stay broken until i finish cleaning up those
patches, here is a patch that moves the type caching so it only
happens for C++ CU's.

Unless other languages make the same guarantees, we can't do the same
optimization.

Diff is making it into more than it is, because moving it into the
cu_language == language_cplus block, changes the indentation of all
the code under it.

I have added the same type of code kevin has to the patches i am
readying.


--Dan


Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.17
diff -c -3 -p -r1.17 dwarf2read.c
*** dwarf2read.c	2000/11/03 22:38:38	1.17
--- dwarf2read.c	2000/11/04 03:05:24
*************** tag_type_to_type (struct die_info *die, 
*** 4532,4547 ****
        attr = dwarf_attr (die, DW_AT_name);
        if (attr && DW_STRING (attr))
  	{
! 	  char *attrname=DW_STRING (attr);
! 	  unsigned long hashval=hash(attrname, strlen(attrname)) % TYPE_HASH_SIZE;
! 
! 	  if (dwarf2_cached_types[hashval] != NULL)
  	    {
! 	      const char *nameoftype;
! 	      nameoftype = TYPE_NAME(dwarf2_cached_types[hashval]) == NULL ? TYPE_TAG_NAME(dwarf2_cached_types[hashval]) : TYPE_NAME(dwarf2_cached_types[hashval]);
! 	      if (strcmp(attrname, nameoftype) == 0)
  		{
! 		  die->type=dwarf2_cached_types[hashval];
  		}
  	      else
  		{
--- 4532,4554 ----
        attr = dwarf_attr (die, DW_AT_name);
        if (attr && DW_STRING (attr))
  	{
! 	  if (cu_language == language_cplus)
  	    {
! 	      char *attrname=DW_STRING (attr);
! 	      unsigned long hashval=hash(attrname, strlen(attrname)) % TYPE_HASH_SIZE;
! 	      if (dwarf2_cached_types[hashval] != NULL)
  		{
! 		  const char *nameoftype;
! 		  nameoftype = TYPE_NAME(dwarf2_cached_types[hashval]) == NULL ? TYPE_TAG_NAME(dwarf2_cached_types[hashval]) : TYPE_NAME(dwarf2_cached_types[hashval]);
! 		  if (strcmp(attrname, nameoftype) == 0)
! 		    {
! 		      die->type=dwarf2_cached_types[hashval];
! 		    }
! 		  else
! 		    {
! 		      read_type_die (die, objfile, cu_header);
! 		      dwarf2_cached_types[hashval] = die->type;
! 		    }
  		}
  	      else
  		{
*************** tag_type_to_type (struct die_info *die, 
*** 4552,4558 ****
  	  else
  	    {
  	      read_type_die (die, objfile, cu_header);
- 	      dwarf2_cached_types[hashval] = die->type;
  	    }
  	}
        else
--- 4559,4564 ----

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

[Kevin Buettner]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3743 bytes --]

[CC to linux-ia64@linuxia64.org trimmed since this is primarly a gdb
matter.]

On Nov 3, 10:20pm, Daniel Berlin wrote:

> > I will leave it to the dwarf2 maintainers to decide whether this
> > patch is acceptable or if it would be better to implement one of
> > Jim's other suggestions.
> > 
> 
> Unfortuantely , this is actually still wrong for languages other than
> C++, because we don't have the same guarantees about uniqueness in the name.
> 
> I was actually in the process of readying patches that add the same
> type of name based caching (based on mangled name) to partial and
> normal symbol reading, which gives us an amazing win for C++.
> 
> These patches also moved all of the name caching into "if (cu_language
> == language_cplus)" blocks, doing what we used to do in the old case
> (IE no caching).
> 
> Rather than let this stay broken until i finish cleaning up those
> patches, here is a patch that moves the type caching so it only
> happens for C++ CU's.

I hereby withdraw my patch from consideration in favor of Daniel's
patch.  In my opinion, Daniel's patch should go in ASAP since the code
in question has been broken since June 5 according to cvs annotate. 
For some reason, the corresponding ChangeLog entry is May 30.

The other alternative is to revert the May 30/June 5 patch.

> Unless other languages make the same guarantees, we can't do the same
> optimization.

Agreed.  I've constructed a small example and have convinced myself that
the code presently in dwarf2read.c is broken for C, but not for C++.

> I have added the same type of code kevin has to the patches i am
> readying.

Good.

You may wish to prepare a new interim patch which has a proper
ChangeLog entry, fixes the formatting of the long ``nameoftype = ...''
line, and which incorporates my proposed fix of not caching the type
unless it has a name or tag name.  This latter check is still
necessary to account for error conditions in reading the type die.  If
you feel that you do not have time to do this, let me know, and I'll
put it together for you.

Kevin
From inksupplies@kt.com.ar Mon Nov 06 18:39:00 2000
From: inksupplies <inksupplies@kt.com.ar>
To: gdb@sourceware.cygnus.com
Subject: Ahora imprima todo y gaste MENOS!!!
Date: Mon, 06 Nov 2000 18:39:00 -0000
Message-id: <e856f62b2cd17d16bf5908f8f627f5eb@NO-ID-FOUND.mhonarc.org>
X-SW-Source: 2000-11/msg00030.html
Content-length: 1348

Title: Si los cartuchos de su impresora a chorro de tinta







    Si los cartuchos de su impresora a chorro de
    tinta 
    Canon - Epson - Hewlett Packard - Lexmark
    
    le resultan caros... CLIQUEE AQUI !!!
    
    Informándonos la marca y modelo de su
    impresora 
    comenzará a ahorrar más de un 50% en sus
    costos de impresión
    NOTA: Su dirección nos
    fue proporcionada como interesada en recibir esta
    información, en caso de no ser así, rogamos disculpar la
    intromisión y responder este mensaje - Cliqueando en el
    siguiente link> Asunto: REMOVE [no recibirá nuevos mensajes] 
    Queremos comunicarnos con Ud.de la forma
    más saludable posible. 
    " NO MALGASTEMOS TANTO PAPEL EN
    PUBLICIDAD Y SE TALARAN MENOS ÁRBOLES" 
    !!! LA UTILIZACION DEL CORREO
    ELECTRÓNICO PRESERVA EL MEDIO AMBIENTE !!!
    Bajo
    el Decreto S.1618 TITULO III aprobado por el 105 Congreso
    base de las normativas internacionales sobre SPAM, esta carta
    no puede ser considerada SPAM mientras incluya una forma de
    ser removido y usted puede hacerlo ahora mismo respondiendo
    este e-mail con "remover" en el asunto. Gracias, y
    disculpe las molestias que pudiéramos haberle ocasionado en
    caso de que ésta información no sea de su interés.

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

[Daniel Berlin]

Kevin Buettner <kevinb@cygnus.com> writes:

> [CC to linux-ia64@linuxia64.org trimmed since this is primarly a gdb
> matter.]
> 
> On Nov 3, 10:20pm, Daniel Berlin wrote:
> 
> > > I will leave it to the dwarf2 maintainers to decide whether this
> > > patch is acceptable or if it would be better to implement one of
> > > Jim's other suggestions.
> > > 
> > 
> > Unfortuantely , this is actually still wrong for languages other than
> > C++, because we don't have the same guarantees about uniqueness in the name.
> > 
> > I was actually in the process of readying patches that add the same
> > type of name based caching (based on mangled name) to partial and
> > normal symbol reading, which gives us an amazing win for C++.
> > 
> > These patches also moved all of the name caching into "if (cu_language
> > == language_cplus)" blocks, doing what we used to do in the old case
> > (IE no caching).
> > 
> > Rather than let this stay broken until i finish cleaning up those
> > patches, here is a patch that moves the type caching so it only
> > happens for C++ CU's.
> 
> I hereby withdraw my patch from consideration in favor of Daniel's
> patch.  In my opinion, Daniel's patch should go in ASAP since the code
> in question has been broken since June 5 according to cvs annotate. 
> For some reason, the corresponding ChangeLog entry is May 30.
> 
> The other alternative is to revert the May 30/June 5 patch.

This may be a better idea, it depends on how people want the patches
broken up, I guess.

It might make more sense to revert the old one, then submit the
patch to re-add caching of types, symbols, and psymbols (each seperately).
As opposed to submitting a patch to fix the caching of types, then add
symbols and psymbols caching.
Makes no difference to me, might seem more logical to someone else.

It was something I had intended to do a long while ago, as it's been
pretty far along for a long while (formatting and changelog entries have
to be finished, and some testcases worked up, but the code itself,
seems to work fine), but i've been sidetracked.


> 
> > Unless other languages make the same guarantees, we can't do the same
> > optimization.
> 
> Agreed.  I've constructed a small example and have convinced myself that
> the code presently in dwarf2read.c is broken for C, but not for C++.

Yup. I've got some comments in the patch that adds similar caching for
symbols and psymbols on why it works, especially since the fact that
it works for statics is dependent on the way the dwarf2 reader works
right now (In particular it resets the cached hash tables at the
beginning of each CU, so you end up with at most one of each
type/symbol/psymbol of a given mangled name per file. ). I also added
warnings and notes in the approriate places saying "If you change the
dwarf2 reader in such a way that it no longer resets the hash tables
at the beginning of each symtab, you'll need to change this code".

> 
> > I have added the same type of code kevin has to the patches i am
> > readying.
> 
> Good.
> 
> You may wish to prepare a new interim patch which has a proper
> ChangeLog entry, fixes the formatting of the long ``nameoftype = ...''
> line, and which incorporates my proposed fix of not caching the type
> unless it has a name or tag name.

I plan on it. It's on my todo list for tomorrow. 

>  This latter check is still
> necessary to account for error conditions in reading the type die. 

Yup.

> you feel that you do not have time to do this, let me know, and I'll
> put it together for you.

I should, my todo list for tomorrow includes this patch, and the partial
symbol lookup fix.

The only reason i haven't submitted it, the changelogs, with an RFA in
the subject, is because i wanted to make sure there was nothing
egregiously wrong with it that anyone else could see before I polish
it and submit.
--Dan

> 
> Kevin

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

[David B Anderson]

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.

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

[Jim Wilson]

>If I understand the situation, the SGI compiler attaches a DW_AT_name
>attribute to array types.  We don't know whether this behavior occurs
>only in C compilation units, or in C++ compilation units as well.

It was the SGI Fortran 90 compiler.  I haven't seen any reports of similar
problems with the SGI C or C++ compilers.

Jim
From ac131313@cygnus.com Tue Nov 07 16:58:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: David Taylor <taylor@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: pathmap or dir command on drugs
Date: Tue, 07 Nov 2000 16:58:00 -0000
Message-id: <3A08A3B5.BE9A4017@cygnus.com>
References: <200011062125.QAA00561@texas.cygnus.com>
X-SW-Source: 2000-11/msg00042.html
Content-length: 1335

David Taylor wrote:

> One camp, by comparison with breakpoints and displays, is:
> 
>     pathmap <from-prefix> <to-prefix>
>     show pathmaps <optional-list>
>     delete pathmaps <optional-list>
> 
> The other camp is
> 
>     pathmap add <from-prefix> <to-prefix>
>     pathmap list <optional-list>
>     pathmap delete <optional-list>
> 
> By further analogy with breakpoints and displays, we could also have:

Regardless of the command syntax, is there a way of doing:

	(gdb) show pathmap
	some complex-jibberish is displayed
	(gdb) set pathmap jibberish

so that the entire path map can be set using a single command (instead
of having to construct it).

Hmm, Yes ok, the directory command doesn't have an equivalent:

(gdb) show directories
Source directories searched: $cdir:$cwd
(gdb) directory /tmp
Source directories searched: /tmp:$cdir:$cwd
(gdb) set directories $cdir:/tmp:/$cwd
No symbol table is loaded.  Use the "file" command.
[[this is an error ok :-)]]
(gdb) show directories
Source directories searched: /tmp:$cdir:$cwd
(gdb) 

:-(


If such an underlying mechanism then, I think, that would be more
useable GUI's (what to add to MI).  The CLI might then add a vineer that
included operations such as ``pathmap add''.

A regex operation sounds useful (if slightly more obtuse for non UNIX
die-hards).

	Andrew