stack call

stack call

[Andrew Cagney]

Phil, Nurdin, Sami, Stan,

I'd like to set up a quick call this morning to discuss next steps for 
stack-back-tracing.  In particular using .debug_info to create a more 
detailed back-trace.

I'll reserve 11 Toronto time.

Andrew

Re: stack call

[Sami Wagiaalla]

> I'll reserve 11 Toronto time.
Count me in.

Re: stack call

[Phil Muldoon]

Andrew Cagney wrote:
> Phil, Nurdin, Sami, Stan,
>
> I'd like to set up a quick call this morning to discuss next steps for 
> stack-back-tracing.  In particular using .debug_info to create a more 
> detailed back-trace.
>
> I'll reserve 11 Toronto time.

Ok.

Re: stack call

[Nurdin Premji]

Phil Muldoon wrote:
> Andrew Cagney wrote:
>> Phil, Nurdin, Sami, Stan,
>>
>> I'd like to set up a quick call this morning to discuss next steps 
>> for stack-back-tracing.  In particular using .debug_info to create a 
>> more detailed back-trace.
>>
>> I'll reserve 11 Toronto time.
>
> Ok.
>
Me too.

Re: stack call

[Kris Van Hees]

A few questions...

1. Is this an open call?  I am willing to bet that I am not the only one
   who is also interested in this topic and would be quite interested in
   technical topics discussion like this (and hopefully able to
   contribute to it).  If not an open call, err, why not? :)
2. If it is an open call, it might be a good idea to post basic
   call-in information, even if things like passcode are best left out
   of emails to public mailing lists.  Can always put in a reference on
   who to ask for the passcode.
3. Can calls like this perhaps be announced a bit more in advance so
   people may be able to make arrangements to join the call?

   	Cheers,
	Kris

On Mon, May 07, 2007 at 10:09:32AM -0400, Andrew Cagney wrote:
> Phil, Nurdin, Sami, Stan,
> 
> I'd like to set up a quick call this morning to discuss next steps for 
> stack-back-tracing.  In particular using .debug_info to create a more 
> detailed back-trace.
> 
> I'll reserve 11 Toronto time.
> 
> Andrew
> 

Re: stack call

[Andrew Cagney]

Notes:

Current state:

npremji, pmuldoon: core and proc models + ABI backtrace
    - npremji is working on getting the ABI stack-backtrace, provided by 
libunwind, working using frysk to get memory et.al.
    - pmuldoon and npremji are looking at how ELFUTILS is bound so it 
too uses frysk to get memory et.al.
    - pmuldoon is filling in the core file side of a frysk.proc model
this will give us an ABI stack backtrace on both core files and on live 
processes; a simple test is "fstack" of a core file

scox: variables, types, locations and expressions
    - getting the type system filled out and working when the variable 
is in static memory (i.e., avoiding complexities of location expressions)
    - also other type system issues such as tab competion
this will get us the ability to display all variables (but with 
limitations on the variables location)

Going forward:

sami to look at the .debug_info code so that frysk's stack model is 
extended to include source level line and function information vis:
    - knowledge that there are multiple functions for a frame
    - knowledge that a function has its line/file
    - ways to display et.al. same
    - work with make on how to use this in the stepping code with mcvet 
; will try to get things so that in-line functions by default behave 
like macros; i.e., step over when next
this will give us the higher level backtrace and start to allow us to 
build out things like scoping and, potentially, variable and other 
information

pmuldoon, npremji: keep going with getting low-level core and process 
frysk.proc working

scox: continue with type system, perhaps with sami, start to look at 
location expression stuff (much overlap).

[side discussion about how elfutils has bindings to return the evaluated 
location expression, sweet]

Andrew


Andrew Cagney wrote:
> Phil, Nurdin, Sami, Stan,
>
> I'd like to set up a quick call this morning to discuss next steps for 
> stack-back-tracing.  In particular using .debug_info to create a more 
> detailed back-trace.
>
> I'll reserve 11 Toronto time.
>
> Andrew
>

Re: stack call

[Andrew Cagney]

Kris,

I would assume impromptu call like this use the standard dial-in numbers 
and are open (i'll be more explicit next time).  And the main goal is to 
facilitate a timely non-technical discussion with the immediate 
players.  For technical discussion, #frysk, frysk@ or Wednesday are 
always the preferred channels.

Andrew

Kris Van Hees wrote:
> A few questions...
>
> 1. Is this an open call?  I am willing to bet that I am not the only one
>    who is also interested in this topic and would be quite interested in
>    technical topics discussion like this (and hopefully able to
>    contribute to it).  If not an open call, err, why not? :)
>   
> 2. If it is an open call, it might be a good idea to post basic
>    call-in information, even if things like passcode are best left out
>    of emails to public mailing lists.  Can always put in a reference on
>    who to ask for the passcode.
>   
> 3. Can calls like this perhaps be announced a bit more in advance so
>    people may be able to make arrangements to join the call?
>   
>    	Cheers,
> 	Kris
>
> On Mon, May 07, 2007 at 10:09:32AM -0400, Andrew Cagney wrote:
>   
>> Phil, Nurdin, Sami, Stan,
>>
>> I'd like to set up a quick call this morning to discuss next steps for 
>> stack-back-tracing.  In particular using .debug_info to create a more 
>> detailed back-trace.
>>
>> I'll reserve 11 Toronto time.
>>
>> Andrew
>>
>>     

Re: stack call

[Sami Wagiaalla]

> sami to look at the .debug_info code so that frysk's stack model is 
> extended to include source level line and function information vis:
>    - knowledge that there are multiple functions for a frame
>    - knowledge that a function has its line/file
>    - ways to display et.al. same
>    - work with make on how to use this in the stepping code with mcvet 
> ; will try to get things so that in-line functions by default behave 
> like macros; i.e., step over when next
> this will give us the higher level backtrace and start to allow us to 
> build out things like scoping and, potentially, variable and other 
> information
Ok so here is a summary of what I will be doing:

As Stan pointed out the above described hierarchy is already in place. 
My work will involve, making sure that the structures are populated 
using the dwarf information, testing, and providing appropriates 
interface for stack examination, and variable inspection.

As Andrew explained test cases will be used to develop, and solidify the 
API. And also to test that is is working :)