print_backtrace not printing full stack

[Mike Mason]

Jim Keniston wrote:
> On Thu, 2006-08-10 at 14:35, Mike Mason wrote:
>> Hmm... I didn't think about the user portion of the stack being missing.
>> Perhaps open() isn't a good example.  I tried probing the entry to open()
>> and printing the backtrace.  Saw the same results.
> 
> You're probing sys_open(), which is dispatched directly from the system
> call table, at least on some architectures.  On i386, I'd expect to see
> an entry for sys_open and one for the code that called sys_open
> (sysenter_past_esp in entry.S), but that's all.  sysenter_past_esp is a
> label in what is essentially the entry point into the kernel for system
> calls.
> 
> Which architecture are you testing?

x86_64.  I just tried the same script on i386 and print_backtrace() works as 
expected.  The problem appears to be x86-64 specific.  I'll file a bug.

> 
>> Then I tried a few
>> other probe points, including schedule() in sched.c.
>> No matter where I
>> probe, I only get one line of the stack.
> 
> That sounds like a bug.  Is that one line in the probed function, in its
> caller, or what?  (I'm assuming you don't see the kretprobe_trampoline
> line if it's not a kretprobe.)

It depends.  If I probe sys_open(), I see sys_open() only.  If I probe 
schedule() in sched.c, I see a line for __sched_text_start and that's all. 
You're right, I only see kretprobe_trampoline for return probes.

> 
> BTW, on powerpc, at least, print_backtrace() reports the bulk of the
> stack trace as one long line, apparently no matter how many functions
> are reported.  Are you seeing just one function reported, or multiple
> functions on one line?

On powerpc, I'm seeing as you describe.  All the functions appear to be 
printed, but most are on one long line.

Mike

> 
>> Mike
> 
> Jim
>