Re: meeting 2007-08-15 9:30 us east coast time

[Andrew Cagney <cagney@redhat.com>]

Three topis:  sami discussing inlined functions; phil/nurdin and 
corefiles and arguments; what should <<frysk PID>> do?

Sami: would like to go some use cases involving inlined code and stack 
frames

Here's the code being discussed:

sami #include <stdlib.h>
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 <<fstack -a>> and <<where -a>>.  In addition, 
"info" be extended to include commands to dump out details, for instance 
<<info locals -- print local variables>> <<info scope -- print static 
scope information>>

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 
<<core>> <<exe>> and "just does the right thing".

------------------------------------

Topic #3: what should <<frysk PID>> 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