From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6238 invoked by alias); 25 Jul 2008 13:54:40 -0000 Received: (qmail 6229 invoked by uid 22791); 25 Jul 2008 13:54:39 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout6.012.net.il (HELO mtaout6.012.net.il) (84.95.2.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Jul 2008 13:54:20 +0000 Received: from HOME-C4E4A596F7 ([84.229.112.15]) by i-mtaout6.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K4K005FFEMBLR10@i-mtaout6.012.net.il> for gdb-patches@sourceware.org; Fri, 25 Jul 2008 16:54:12 +0300 (IDT) Date: Fri, 25 Jul 2008 13:54:00 -0000 From: Eli Zaretskii Subject: Re: [FYI] Inlining support, rough patch In-reply-to: <20080715192020.GB3094@caradoc.them.org> X-012-Sender: halo1@inter.net.il To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: References: <20080613152754.GA4220@caradoc.them.org> <20080715192020.GB3094@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00438.txt.bz2 > Date: Tue, 15 Jul 2008 15:20:20 -0400 > From: Daniel Jacobowitz > > Eli, when you have a chance, could you look at the NEWS / gdb.texinfo > changes? I've added a new section, though it is somewhat sparse at > present. Yes, it would be good to populate it with additional information about debugging optimized code. > +There are some ways that @value{GDBN} cannot pretend that inlined > +function calls are the same as normal calls: > + > +@itemize @bullet > +@item > +You cannot set breakpoints on inlined functions. @value{GDBN} > +either reports that there is no symbol with that name, or else sets the > +breakpoint on the non-inlined copy of the function. > + > +@item > +Setting breakpoints at the call site of an inlined function may not > +work, because the call site does not contain any code. @value{GDBN} > +may incorrectly move the breakpoint to the next line of the enclosing > +function, after the call. > + > +@item > +@value{GDBN} cannot locate the return value of inlined calls after > +using the @code{finish} command. > + > +@end itemize This is IMO too negative: you state several problems and never hint on how to work around them. Please consider suggesting such workarounds in each one of the above 3 situations. Using breakpoints and returned values reported by `finish' are two very fundamental debugging techniques; telling the readers that they are simply unavailable will lead them to believe debugging code that uses inlined functions is next to impossible. Otherwise, this part is okay. Thanks. > Index: src/gdb/NEWS > =================================================================== > --- src.orig/gdb/NEWS 2008-07-15 15:15:22.000000000 -0400 > +++ src/gdb/NEWS 2008-07-15 15:16:05.000000000 -0400 > @@ -17,6 +17,9 @@ For instance, consider: > If the user types TAB at the end of this command line, the available > completions will be "f1" and "f2". > > +* Inlined functions are now supported. They show up in backtraces, and > +the "step", "next", and "finish" commands handle them automatically. > + This is fine.