All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Mosberger <davidm@napali.hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] get_scratch_regs in bk 2.4 unwind.c
Date: Mon, 10 Mar 2003 17:00:51 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590709806018@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590709806009@msgid-missing>

>>>>> On Sat, 08 Mar 2003 14:57:11 +1100, Keith Owens <kaos@sgi.com> said:

  Keith> UNW_DPRINT(3, "unwind.%s: sp 0x%lx pt 0x%lx\n", __FUNCTION__, info->sp, info->pt);

  Keith> __FUNCTION__ will always print get_scratch_regs which is of no use, we
  Keith> need the calling function.  My patch passed in the calling function
  Keith> name as a parameter.  Please revert to passing in the function name or
  Keith> make get_scratch_regs a #define so it gets the calling function name.
  Keith> Also I printed the new value of info->pt, it is useful when debugging
  Keith> bad unwind data.

We're not going to pass around arguments that are only used for
debugging.  If you want to, we could print __builtin_return_address(0)
along with the function name (or we could use the kernel symbol table
to print the symbolic name).

  Keith> unw_access_gr has

  Keith> /* access a scratch register */
  Keith> if (!info->pt) {
  Keith> UNW_DPRINT(0, "unwind.%s: no pt-regs; cannot access r%d\n",
  Keith> __FUNCTION__, regnum);
  Keith> return -1;
  Keith> }
  Keith> pt = get_scratch_regs(info);

  Keith> Why the test for !info->pt?  No other use of get_scratch_regs
  Keith> has that test, unw_access_[abf]r will continue with whatever
  Keith> data get_scratch_regs returns, using pt_regs on top of stack
  Keith> if info->pt is undefined.  The code is inconsistent.

I agree.  Looks like something went wrong during the merge.  I'll fix
that.

	--david


      reply	other threads:[~2003-03-10 17:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-08  3:57 [Linux-ia64] get_scratch_regs in bk 2.4 unwind.c Keith Owens
2003-03-10 17:00 ` David Mosberger [this message]

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=marc-linux-ia64-105590709806018@msgid-missing \
    --to=davidm@napali.hpl.hp.com \
    --cc=linux-ia64@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.