From mboxrd@z Thu Jan 1 00:00:00 1970 From: David B Anderson To: gdb@sources.redhat.com Subject: Re: [Linux-ia64] Re: gdb null ptr Date: Thu, 09 Nov 2000 14:03:00 -0000 Message-id: <200011092201.OAA10521@quasar.engr.sgi.com> X-SW-Source: 2000-11/msg00048.html Jim Blandy 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 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 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 replaces the current list of search paths with dir1,dir2. example: use /abc /def use print the list of directory paths dir 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 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 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 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 : 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: : 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 : stwu r1,-128(r1) (chgdb) x/10i N_iom:printf 0xa00dafc4 : 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 : stwu r1,-128(r1) (chgdb) x/i N_iom:printf 0xa00dafc4 : 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 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.