All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xin Zhao <uszhaoxin@gmail.com>
To: bert hubert <bert.hubert@netherlabs.nl>,
	Xin Zhao <uszhaoxin@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Why dump_stack results different so much?
Date: Fri, 29 Jul 2005 17:00:20 -0400	[thread overview]
Message-ID: <4ae3c140507291400230ca65c@mail.gmail.com> (raw)
In-Reply-To: <20050729203403.GA30603@outpost.ds9a.nl>

Thanks for your reply.

Below is the code that print the kernel calling trace:

/**********************************************************************************/
void show_trace(struct task_struct *task, unsigned long * stack)
{
	unsigned long ebp;

	if (!task)
		task = current;

	if (task == current) {
		/* Grab ebp right from our regs */
		asm ("movl %%ebp, %0" : "=r" (ebp) : );
	} else {
		/* ebp is the last reg pushed by switch_to */
		ebp = *(unsigned long *) task->thread.esp;
	}

	while (1) {
		struct thread_info *context;
		context = (struct thread_info *)
			((unsigned long)stack & (~(THREAD_SIZE - 1)));
		ebp = print_context_stack(context, stack, ebp);
		stack = (unsigned long*)context->previous_esp;
		if (!stack)
			break;
		printk(" =======================\n");
	}
}
/**********************************************************************************/

>From this code, I can see that the show_trace does not scan and guess
the pointers. Instead, it use "previous_esp" to extract the esp and
thus the returning eip. Am I right?

Cheers,
xin




On 7/29/05, bert hubert <bert.hubert@netherlabs.nl> wrote:
> On Fri, Jul 29, 2005 at 04:27:16PM -0400, Xin Zhao wrote:
> > I supprisely noticed that the dump_stack results are quite different!
> > Why did I get the calling traces below our_ssy_open() and above
> > syscall_call()?  Any thought on this? Many thanks!
> 
> This might depend on compiling with frame pointers, or not. I recall that at
> one point, the kernel did a basic scan of addresses that looked like likely
> candidates to have been pointers, and printed those.
> 
> Frame pointers are hailed as improving backtraces. They are in the 'kernel
> hacking' section of the kernel configuration.
> 
> Sorry that I can't be more precise, but try turning on frame pointers.
> 
> Good luck!
> 
> --
> http://www.PowerDNS.com      Open source, database driven DNS Software
> http://netherlabs.nl              Open and Closed source services
>

  reply	other threads:[~2005-07-29 21:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-29 20:27 Why dump_stack results different so much? Xin Zhao
2005-07-29 20:34 ` bert hubert
2005-07-29 21:00   ` Xin Zhao [this message]
2005-07-29 21:22     ` bert hubert
2005-07-30  0:10       ` Xin Zhao
2005-07-30 11:52         ` bert hubert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ae3c140507291400230ca65c@mail.gmail.com \
    --to=uszhaoxin@gmail.com \
    --cc=bert.hubert@netherlabs.nl \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.