From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17812 invoked by alias); 15 Aug 2007 15:56:21 -0000 Received: (qmail 17377 invoked by uid 22791); 15 Aug 2007 15:56:17 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 15 Aug 2007 15:56:08 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l7FFu6ZW017955 for ; Wed, 15 Aug 2007 11:56:06 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l7FFu5oE000727 for ; Wed, 15 Aug 2007 11:56:05 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l7FFu3GV017604 for ; Wed, 15 Aug 2007 11:56:04 -0400 Message-ID: <46C32222.9030506@redhat.com> Date: Wed, 15 Aug 2007 15:56:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: frysk@sourceware.org Subject: Re: meeting 2007-08-15 9:30 us east coast time References: <46C257B2.5030903@redhat.com> In-Reply-To: <46C257B2.5030903@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00303.txt.bz2 Three topis: sami discussing inlined functions; phil/nurdin and corefiles and arguments; what should <> do? Sami: would like to go some use cases involving inlined code and stack frames Here's the code being discussed: sami #include sami inline void third(int arg3){ sami int var3 = arg3; sami int* a = 0; sami a[0] = var3; sami } sami inline void second(int arg2){ sami int var2 = arg2; sami third(var2+1); sami } sami inline void first(int arg1){ sami int var1 = arg1; sami second(var1+1); sami } sami int main(){ sami int some_int = 1; sami first(some_int); sami return 0; sami } and here's the output from the current fstack -a: sami #0 0x0000000000400466 in third(int arg3 = < ERROR >) /to/scratch/swagiaal/frysks/frysk.testBuild/frysk-core/frysk/pkglibdir/funit-inlined.c#6 sami int var3 = < value unavailable at pc=0x400466> line#< error > sami * a = < value unavailable at pc=0x400466> line#< error > sami #1 0x0000000000400466 in second(int arg2 = < optimized out >) /to/scratch/swagiaal/frysks/frysk.testBuild/frysk-core/frysk/pkglibdir/funit-inlined.c#6 sami int var2 = < value unavailable at pc=0x400466> line#< error > sami int var3 = < value unavailable at pc=0x400466> line#< error > sami * a = < value unavailable at pc=0x400466> line#< error > sami #2 0x0000000000400466 in first(int arg1 = < optimized out >) /to/scratch/swagiaal/frysks/frysk.testBuild/frysk-core/frysk/pkglibdir/funit-inlined.c#6 sami int var1 = < value unavailable at pc=0x400466> line#< error > sami int var2 = < value unavailable at pc=0x400466> line#< error > sami int var3 = < value unavailable at pc=0x400466> line#< error > sami * a = < value unavailable at pc=0x400466> line#< error > sami #3 0x0000000000400466 in main () from /tmp/frysks/frysk.testBuild/frysk-core/frysk/pkglibdir/funit>> -- Discussion 1: What output should each "rich" or "inline" frame contain? From inline frame #1 (second): int var2 = < value unavailable at pc=0x400466> line#< error > int var3 = < value unavailable at pc=0x400466> line#< error > * a = < value unavailable at pc=0x400466> line#< error > and notice how it lists variables from both second(var2) and third(var3,a). Should inline frames display just their local variables (reflecting the source) or both their and nested inline scopes (reflecting the DIE information). Long discussion which identified that both dynamic and static information can be displayed: dynamic: given an inline instance, display that instances variables only static: given a function containing inline instances, display the full inline information including scopes created by inlining and the default should be the dynamic info (i.e., inline function display just their local variables) but there be a way to display the static information with additional mark-ups to identify nested inlined functions and their scopes. Discussion #2: What should <<(fhpd) where>> display, should it follow fstack (Side bar, fstack's default is to display just a raw stack using ELF information only so that it is simple and fast; there isn't a good reason for mimicking it). Discussion concluded (fhpd)where should: + include inline functions (performance isn't an issue, full information is) + include function signatures (e.g., String foo(int,boolean)) (lets cut/paste of that for setting breakpoints and easy identification of parameters, but avoids problems of parameter values being wrong) + include file/line (I guess?) - no local variables - no parameters Discussion 3: Commands / options for accessing stack information. Discussion concluded that "where" should broadly follow fstack's option convention; for instance <> and <>. In addition, "info" be extended to include commands to dump out details, for instance <> <> Discussion 4: How should frames be identified. Discussion identified that using simple numbering (#0 #1 #2) for inline frames would lead to frames being identified by different numbers dependant on the presence of inline debug info, and would not help identify inline vs true frames. Its proposed that a Dewey Decimal notation be adopted for instance, using the above: #0.1 third #0.2 second #0.3 first #0 main where there is no nested frame 0 (too confusing over it being either main or third) ---------------------------------- Topic #2 (phil/nurdin) core files needing executables Background: there are times when, to read a corefule, the executable that the core originated from needs to also be supplied. This is due to the core not containing the full path to the executable or that executable path being wrong (e.g., out-of-date). Nurdin explained how the generic command line parser (used by all commands) will recognize <> <> and "just does the right thing". ------------------------------------ Topic #3: what should <> do It was concluded that the answer depends largely on what tool you worked on last; it could bring up either the monitor or the source window. Ignoring the "vote" solution, several options were suggested: - jump to the "session assistant" and, when the process-picker window is displayed have it pre-populated with the list of pids - add --debug | --monitor options