fstack options

fstack options

[Sami Wagiaalla]

right now fstack prints a stack trace using only elf information. I 
would like to add the following options to it:

fstack --print={options}
where options include:
functions, scopes, parameters, fullpath

functions: prints function names using debug info
scopes: print function scopse and their respective variables
parameters: print function parameters
fullpath: print full source file path instead of just the file name

the default set can be whatever.

any comments on default params, option names, etc ?



Sami

Re: fstack options

[Sami Wagiaalla]

Sami Wagiaalla wrote:
> right now fstack prints a stack trace using only elf information.
Although this is still the default, personally I think  the default 
should be print function names and parameters if debuginfo is available 
other wise fall back to elf symbol. And provide an option for getting an 
elf only stack back trace.

Re: fstack options

[Andrew Cagney]

fstack's, and its pre-cursors - gstack and pstack, first priority is 
speed - get in, get a backtrace, get out - and I think it is fair to 
assume that having to scan multi-megabytes of .debug info would run 
against that goal (fstack probably shouldn't look in .debug_line by 
default either).

Perhaps an option << fstack -a >> to reverse the goal and display 
everything known about the function would address this.

Andrew


Sami Wagiaalla wrote:
> Sami Wagiaalla wrote:
>> right now fstack prints a stack trace using only elf information.
> Although this is still the default, personally I think  the default 
> should be print function names and parameters if debuginfo is 
> available other wise fall back to elf symbol. And provide an option 
> for getting an elf only stack back trace.

Re: fstack options

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On Thu, 2007-06-14 at 13:51 -0400, Andrew Cagney wrote:
> fstack's, and its pre-cursors - gstack and pstack, first priority is 
> speed - get in, get a backtrace, get out - and I think it is fair to 
> assume that having to scan multi-megabytes of .debug info would run 
> against that goal (fstack probably shouldn't look in .debug_line by 
> default either).
> 
> Perhaps an option << fstack -a >> to reverse the goal and display 
> everything known about the function would address this.

So would a 2 stage approach be an idea. fstack just gets the addresses
on the stack, writes them out (or buffers them) and gets out. Then the
result gets pushed through addr2line (or a frysk based alternative if
you want) that pieces together the actual source lines from the
addresses and the exe associated with the pid?

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: fstack options

[Andrew Cagney]

Mark,

A two stage pass might work for an elf based backtrace as only the code 
addresses and address map need to be saved.  However, for a more 
detailed backtrace, involving variable values et.al. the debug info 
needs to be scanned during the first pass to determine what to save for 
that second pass.

Andrew

Mark Wielaard wrote:
> On Thu, 2007-06-14 at 13:51 -0400, Andrew Cagney wrote:
>   
>> fstack's, and its pre-cursors - gstack and pstack, first priority is 
>> speed - get in, get a backtrace, get out - and I think it is fair to 
>> assume that having to scan multi-megabytes of .debug info would run 
>> against that goal (fstack probably shouldn't look in .debug_line by 
>> default either).
>>
>> Perhaps an option << fstack -a >> to reverse the goal and display 
>> everything known about the function would address this.
>>     
>
> So would a 2 stage approach be an idea. fstack just gets the addresses
> on the stack, writes them out (or buffers them) and gets out. Then the
> result gets pushed through addr2line (or a frysk based alternative if
> you want) that pieces together the actual source lines from the
> addresses and the exe associated with the pid?
>
> Cheers,
>
> Mark
>