This is the mail archive of the gdb-prs@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]
Other format: [Raw text]

pending/998: [RFA/PATCH] Behavior of gdb with -fullname and -interpreter=mi


>Number:         998
>Category:       pending
>Synopsis:       [RFA/PATCH] Behavior of gdb with -fullname and -interpreter=mi
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   unknown
>Arrival-Date:   Fri Jan 31 05:38:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 2002-12-10  Dennis Brueni <dennis@slickedit.com>
 
 	* stack.c: honor -fullname option when printing stack dump
 
 Index: stack.c
 ===================================================================
 RCS file: /cvs/src/src/gdb/stack.c,v
 retrieving revision 1.58
 diff -c -p -b -r1.58 stack.c
 *** stack.c	9 Dec 2002 03:30:44 -0000	1.58
 --- stack.c	10 Dec 2002 20:03:26 -0000
 *************** print_frame (struct frame_info *fi,
 *** 553,559 ****
 --- 553,563 ----
          ui_out_wrap_hint (uiout, "   ");
          ui_out_text (uiout, " at ");
          annotate_frame_source_file ();
 +       if (annotation_level >= 1) {
 +          ui_out_field_string (uiout, "file", symtab_to_filename(sal.symtab));
 +       } else {
             ui_out_field_string (uiout, "file", sal.symtab->filename);
 +       }
          annotate_frame_source_file_end ();
          ui_out_text (uiout, ":");
          annotate_frame_source_line ();
 
 
 ===================================================================
 
 Problem:
 
      When using gdb with -interpreter=mi and the -fullname option,
      the stack dumps still show file names using relative paths
      rather than the fully qualified path you would expect.
 
      When in MI mode, the annotations that would normally show the
      fully qualified path are not produced.
 
 Description:
 
      The fix simply attempts to find the fully qualified path to
      the source file if -fullname is given, independent of the
      interpreter mode.  This works perfectly for the MI mode, and
      I think it is fair to argue that it should be the expected
      behavior for all other modes as well.
 
 Fix Description:
 
      Four line modification to stack.c in the print_frame() function.
 
 Notes:
 
      The modification makes -fullname do what I expect it to do, however,
      I do acknowledge that existing software that controls GDB, for example,
      emacs, may expect only the annotations to be fully qualified.  So this
      change may break those programs.
 
      In the -interpreter=mi case, since the annotations are not produced,
      I believe that, without this patch, -fullname is broken.
 
      Given my druthers, I would rather see -fullname behave consistently
      rather than working in one mode and not in another.
 
      If this fix is accepted, it would be great if it made the 5.4 release.
 
 
 Examples [before]:
 
      [dbrueni@falcon gdb]$ ./gdb -fullname ./gdb
      GNU gdb 2002-12-10-cvs
      Copyright 2002 Free Software Foundation, Inc.
      GDB is free software, covered by the GNU General Public License, and you are
      welcome to change it and/or distribute copies of it under certain conditions.
      Type "show copying" to see the conditions.
      There is absolutely no warranty for GDB.  Type "show warranty" for details.
      This GDB was configured as "i686-pc-linux-gnu"...
      Setting up the environment for debugging gdb.
      During symbol reading, struct/union type gets multiply defined: struct objfile.
      Breakpoint 1 at 0x80f3937: file utils.c, line 799.
      Breakpoint 2 at 0x807c6ce: file ./cli/cli-cmds.c, line 202.
      (top-gdb) break main
      Breakpoint 3 at 0x807791c: file gdb.c, line 28.
      (top-gdb) run
      Starting program: /home/dbrueni/gdb-latest/src/gdb/gdb
 
      Breakpoint 3, main (argc=1, argv=0xbffffb14) at gdb.c:28
      <</home/dbrueni/gdb-latest/src/gdb/gdb.c:28:926:beg:0x807791c
      (top-gdb) quit
      The program is running.  Exit anyway? (y or n) y
 
 
      [dbrueni@falcon gdb]$ ./gdb -fullname -interpreter=mi ./gdb
      ~"GNU gdb 2002-12-10-cvs\n"
      ~"Copyright 2002 Free Software Foundation, Inc.\n"
      ~"GDB is free software, covered by the GNU General Public License, and you are\n"
      ~"welcome to change it and/or distribute copies of it under certain conditions.\n"
      ~"Type \"show copying\" to see the conditions.\n"
      ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
      ~"This GDB was configured as \"i686-pc-linux-gnu\"..."
      ~"\n"
      ~"Setting up the environment for debugging gdb.\n"
      During symbol reading, struct/union type gets multiply defined: struct objfile.
      ~"Breakpoint 1 at 0x80f3937: file utils.c, line 799.\n"
      ~"Breakpoint 2 at 0x807c6ce: file ./cli/cli-cmds.c, line 202.\n"
      (gdb)
      break main
      &"break main\n"
      ^done
      (gdb)
      run
      &"run\n"
      ^done,reason="breakpoint-hit",bkptno="3",thread-id="0",frame={addr="0x0807791c",
      func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffffb14"}],file
      ="gdb.c",line="28"}
      (gdb)
      quit
      &"quit\n"
      ~"The program is running.  Exit anyway? (y or n) "
 
 Notice that when the breakpoing is hit, in both cases, except for the annotation,
 the stack location is reported using only the relative source file name (gdb.c),
 not the fully qualified name I would expect because I used the -fullname option.
 
 Example [after]:
 
      [dbrueni@falcon gdb]$ ./gdb -fullname ./gdb
      GNU gdb 2002-12-10-cvs
      Copyright 2002 Free Software Foundation, Inc.
      GDB is free software, covered by the GNU General Public License, and you are
      welcome to change it and/or distribute copies of it under certain conditions.
      Type "show copying" to see the conditions.
      There is absolutely no warranty for GDB.  Type "show warranty" for details.
      This GDB was configured as "i686-pc-linux-gnu"...
      Setting up the environment for debugging gdb.
      During symbol reading, struct/union type gets multiply defined: struct objfile.
      Breakpoint 1 at 0x80f3963: file utils.c, line 799.
      Breakpoint 2 at 0x807c6ce: file ./cli/cli-cmds.c, line 202.
      (top-gdb) break main
      Breakpoint 3 at 0x807791c: file gdb.c, line 28.
      (top-gdb) run
      Starting program: /home/dbrueni/gdb-latest/src/gdb/gdb
 
      Breakpoint 3, main (argc=1, argv=0xbffffb14)
          at /home/dbrueni/gdb-latest/src/gdb/gdb.c:28
      <</home/dbrueni/gdb-latest/src/gdb/gdb.c:28:926:beg:0x807791c
      (top-gdb) quit
      The program is running.  Exit anyway? (y or n) y
 
 
      [dbrueni@falcon gdb]$ ./gdb -fullname -interpreter=mi ./gdb
      ~"GNU gdb 2002-12-10-cvs\n"
      ~"Copyright 2002 Free Software Foundation, Inc.\n"
      ~"GDB is free software, covered by the GNU General Public License, and you are\n"
      ~"welcome to change it and/or distribute copies of it under certain conditions.\n"
      ~"Type \"show copying\" to see the conditions.\n"
      ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
      ~"This GDB was configured as \"i686-pc-linux-gnu\"..."
      ~"\n"
      ~"Setting up the environment for debugging gdb.\n"
      During symbol reading, struct/union type gets multiply defined: struct objfile.
      ~"Breakpoint 1 at 0x80f3963: file utils.c, line 799.\n"
      ~"Breakpoint 2 at 0x807c6ce: file ./cli/cli-cmds.c, line 202.\n"
      (gdb)
      break main
      &"break main\n"
      ^done
      (gdb)
      run
      &"run\n"
      ^done,reason="breakpoint-hit",bkptno="3",thread-id="0",frame={addr="0x0807791c",
      func="main",args=[{name="argc",value="1"},{name="argv",value="0xbffffb14"}],file
      ="/home/dbrueni/gdb-latest/src/gdb/gdb.c",line="28"}
      (gdb)
      quit
      &"quit\n"
      ~"The program is running.  Exit anyway? (y or n) "
      y
 
 
 
 
 Enjoy in moderation,
 
 --Dennis
 
 
 -- 
 ----------------------------------
 Dennis Brueni
 Software Engineer
 SlickEdit Inc.
 3000 Aerial Center Pkwy, Suite 120
 Morrisville, NC  27560
 Phone: 919.473.0132
 Fax: 919.473.0080
 dennis@slickedit.com
 www.slickedit.com
 ----------------------------------
 
 
 
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:


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