[Crash-utility] function arguments

[Dave Anderson]

Shahar Luxenburg wrote:
> Hi,
> 
>  
> 
> I'm using crash utility on RHEL 5 on x86. According to the TODO list 
> 'bt' command should show function arguments: "Display arguments in the 
> stack trace. At present, we do not have support for PPC64 and x86_64". 
> Unfortunately, no function arguments are presented using 'bt' command. 
> Am I missing something?
> 
>  
> 
> If that's the case, I'd like to add that feature (for x86 architecture 
> at first).  Code from kdb can be ported to the crash utility for that 
> purpose. kdb is analyzing the code using basic blocks, understanding 
> where the registers are being saved (either to other registers or memory 
> location) and if their values can be retrieved, it prints them. Can I 
> use debug information for that purpose? I can look at the eh_frame 
> section to understand where ebx, edi, esi and ebp are saved but I can 
> not find information, for each frame, what is the fate of eax, edx and 
> ecx – If I'd know that, then either they were saved in memory (stack 
> location) – it's easy to get them, or they were saved in another 
> register, than I can use the debug information to understand if they 
> were saved on the stack at some 'younger' frame.
> 
>  
> 
> Any hint will be welcomed.
> 
>  
> 
> Regards,
> 
> Shahar.
> 

You can go back in the archives and find several more discussions regarding
your question, but this is the most recent:

   https://www.redhat.com/archives/crash-utility/2008-July/msg00000.html

Basically the ia64 is the only architecture that can display function
arguments, and that's because the capability of doing so is built
into the kernel, and so I essentially ported the kernel ia64 unwind
facility into the crash utility, and with that in place, accessing
function arguments came along with it.

For all other arches, all bets are off.  And in fact, the backtraces
themselves are pretty much educated guesses because the stack frame
size determination is a best-guess when -fomit-frame-pointer is in
place.  So until that functionality is absolutely rock-solid, getting
function arguments is secondary.

Hence, the you-got-to-be-able-to-walk-before-you-run analogy...

Anyway, nothing's impossible, but nobody's come up with a working
strategy yet.  And I welcome all attempts...

Dave