From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25852 invoked by alias); 7 Feb 2003 18:04:38 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25845 invoked from network); 7 Feb 2003 18:04:38 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by 172.16.49.205 with SMTP; 7 Feb 2003 18:04:38 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id h17I4bI18928 for ; Fri, 7 Feb 2003 10:04:37 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 7 Feb 2003 10:04:35 -0800 Received: from apple.com ([17.112.76.147]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id h17I4Zs28148 for ; Fri, 7 Feb 2003 10:04:35 -0800 (PST) Date: Fri, 07 Feb 2003 18:04:00 -0000 Subject: Re: GDB/MI absolute path Content-Type: multipart/mixed; boundary=Apple-Mail-2--238118683 Mime-Version: 1.0 (Apple Message framework v551) From: Jim Ingham To: gdb@sources.redhat.com In-Reply-To: <1044623213.10462.ezmlm@sources.redhat.com> Message-Id: <9D1020EE-3AC6-11D7-AF87-000A277A8808@apple.com> X-SW-Source: 2003-02/txt/msg00154.txt.bz2 --Apple-Mail-2--238118683 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Content-length: 1249 Bob, We actually found that even when run from a GUI, you need absolute paths for files sometimes. The reason for this is that the user may have several projects, say one which builds a shared library, and one an app that uses it. If debugging with the app project open, but not the shlib project, you can end up in a frame with debug info referring to sources you don't know about. For our purposes, we found it sufficient to add the dir path to the -stack-list-frames command. Pretty much the only time we would not know where a file was was when gdb stopped, and we were fetching the stack. You might also want it in the mi -break-insert command as well, if you want to map from breakpoints to files in you UI, dunno... Anyway, we did this by adding a "frame_more_info" hook to the ordinary stack.c frame printing. We haven't needed to add anything but the directory yet, but this does seem a place where more info might be useful in the future, so... Anyway, if you are interested, here is a patch against the FSF TOT. It's hacked out of our sources - we haven't merged back from the interpreter branch yet, so there are a lot of differences between our sources & the FSF. But this is pretty simple, and should work. --Apple-Mail-2--238118683 Content-Disposition: attachment; filename=mi-more-stack.diff Content-Transfer-Encoding: 7bit Content-Type: application/octet-stream; x-unix-mode=0644; name="mi-more-stack.diff" Content-length: 4812 Index: defs.h =================================================================== RCS file: /cvs/src/src/gdb/defs.h,v retrieving revision 1.112 diff -c -w -p -r1.112 defs.h *** defs.h 4 Feb 2003 18:07:00 -0000 1.112 --- defs.h 7 Feb 2003 17:52:51 -0000 *************** extern void (*show_load_progress) (const *** 1166,1171 **** --- 1166,1174 ---- extern void (*print_frame_info_listing_hook) (struct symtab * s, int line, int stopline, int noerror); + extern void (*print_frame_more_info_hook) (struct ui_out *uiout, + struct symtab_and_line *sal, + struct frame_info *fi); extern struct frame_info *parse_frame_specification (char *frame_exp); extern int (*query_hook) (const char *, va_list); extern void (*warning_hook) (const char *, va_list); Index: stack.c =================================================================== RCS file: /cvs/src/src/gdb/stack.c,v retrieving revision 1.65 diff -c -w -p -r1.65 stack.c *** stack.c 2 Feb 2003 18:30:56 -0000 1.65 --- stack.c 7 Feb 2003 17:52:51 -0000 *************** print_frame (struct frame_info *fi, *** 452,457 **** --- 452,460 ---- annotate_frame_source_end (); } + if (print_frame_more_info_hook) + print_frame_more_info_hook (uiout, &sal, fi); + #ifdef PC_SOLIB if (!funname || (!sal.symtab || !sal.symtab->filename)) { Index: top.c =================================================================== RCS file: /cvs/src/src/gdb/top.c,v retrieving revision 1.71 diff -c -w -p -r1.71 top.c *** top.c 6 Feb 2003 01:19:12 -0000 1.71 --- top.c 7 Feb 2003 17:52:52 -0000 *************** void (*command_loop_hook) (void); *** 206,211 **** --- 206,216 ---- void (*print_frame_info_listing_hook) (struct symtab * s, int line, int stopline, int noerror); + + void (*print_frame_more_info_hook) (struct ui_out *uiout, + struct symtab_and_line *sal, + struct frame_info *fi); + /* Replaces most of query. */ int (*query_hook) (const char *, va_list); Index: mi/mi-cmd-stack.c =================================================================== RCS file: /cvs/src/src/gdb/mi/mi-cmd-stack.c,v retrieving revision 1.13 diff -c -w -p -r1.13 mi-cmd-stack.c *** mi/mi-cmd-stack.c 29 Nov 2002 19:15:16 -0000 1.13 --- mi/mi-cmd-stack.c 7 Feb 2003 17:52:52 -0000 *************** *** 32,37 **** --- 32,44 ---- we pull the plug on the sanitization. */ extern void select_frame_command_wrapper (char *, int); + /* Use this to print any extra info in the stack listing output that is + not in the standard gdb printing */ + + void mi_print_frame_more_info (struct ui_out *uiout, + struct symtab_and_line *sal, + struct frame_info *fi); + static void list_args_or_locals (int locals, int values, struct frame_info *fi); /* Print a list of the stack frames. Args can be none, in which case *************** mi_cmd_stack_list_frames (char *command, *** 101,106 **** --- 108,127 ---- error ("mi_cmd_stack_list_frames: Not enough frames in stack."); return MI_CMD_DONE; + } + + void + mi_print_frame_more_info (struct ui_out *uiout, + struct symtab_and_line *sal, + struct frame_info *fi) + { + /* I would feel happier if we used ui_out_field_skip for all the fields + that we don't know how to set (like the file if we don't have symbols) + but the rest of print_frame just omits the fields if they are not known, + so I will do the same here... */ + + if (sal && sal->symtab && sal->symtab->dirname) + ui_out_field_string (uiout, "dir", sal->symtab->dirname); } enum mi_cmd_result Index: mi/mi-interp.c =================================================================== RCS file: /cvs/src/src/gdb/mi/mi-interp.c,v retrieving revision 1.2 diff -c -w -p -r1.2 mi-interp.c *** mi/mi-interp.c 6 Feb 2003 05:30:17 -0000 1.2 --- mi/mi-interp.c 7 Feb 2003 17:52:52 -0000 *************** static int mi_interp_query_hook (const c *** 60,65 **** --- 60,70 ---- static char *mi_interp_read_one_line_hook (char *prompt, int repeat, char *anno); + /* There should be a generic mi .h file where these should go... */ + extern void mi_print_frame_more_info (struct ui_out *uiout, + struct symtab_and_line *sal, + struct frame_info *fi); + static void mi2_command_loop (void); static void mi1_command_loop (void); *************** mi_interpreter_resume (void *data) *** 129,134 **** --- 134,140 ---- clear_interpreter_hooks (); show_load_progress = mi_load_progress; + print_frame_more_info_hook = mi_print_frame_more_info; /* If we're _the_ interpreter, take control. */ if (current_interp_named_p (INTERP_MI1)) --Apple-Mail-2--238118683 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Content-length: 2440 In general, I would prefer working in two directions for this sort of thing. First, we like to try to reduce the number of round trips between the UI and gdb for performance reasons, so when - like this - it is pretty obvious that a piece of info is generally useful when you issue some command, we try to include it in the return from that command. Second, it is nice to keep the MI simple and declarative, so if you think there will be cases other than when you have a stack in front of you that you will need the full path to a file, I would add an explicit command to get this result... You have to balance these two desires so you don't get bloated command returns, but you also don't have to go many identical round trips for common operations. Hope this helps, Jim On Friday, February 7, 2003, at 05:06 AM, gdb-digest-help@sources.redhat.com wrote: > Thanks for the great answer. > > On Thu, Feb 06, 2003 at 02:17:30PM -0800, Keith Seitz wrote: >> On Thu, 2003-02-06 at 13:55, Bob Rossi wrote: >>> Also, what is the best way to ask mi for the absolute path to the >>> current source file. This wasn't a problem using annotate 1 or 2, >>> and I >>> can't figure out how to get it using mi. >> >> This is a known (to me) problem with MI. The problem is that MI was >> designed to work with an IDE, not just a stand-alone GUI for the >> debugger. In the case of an IDE, this information isn't needed, since >> the IDE knows everything there is to know about files. >> >> However, like Insight, cgdb will need some way of turning >> "../foo/bar/baz.c" into "/home/a/b/c/foo/bar/baz.c". There are two >> options (excluding hacks around the problem): >> >> 1. Get the complete source search path from GDB and let the GUI search >> for the file. This means the GUI writer would also need the compile >> directory for each file. >> >> 2. Get GDB to tell you where it thinks a file is located. > > I would like to write a patch to GDB/MI and send it in with a bug > report. Does any of the GDB/MI maintainers know if the current design > model of GDB/MI would prefer an implicit return of the current > absolute path ( like annotations ) or an explicit return ( the GUI > requests it every time via a new GDB/MI command). > > Thanks > Bobby > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Jim Ingham jingham@apple.com Developer Tools - gdb --Apple-Mail-2--238118683--