Re: [Linux-ia64] [patch] 2.4.20-ia64-021210 new spinlock code

David Mosberger
2003-03-27T20:29:04Z

>>>>> On Sat, 15 Mar 2003 21:31:53 +1100, Keith Owens <kaos@sgi.com> said:

Keith> On Fri, 14 Mar 2003 22:46:28 -0800,
Keith> David Mosberger <davidm@napali.hpl.hp.com> wrote:
>> I thought about it some more and recalled why I was so uneasy about
>> claiming ar.pfs is 0: the problem is that this informs that the
>> _previous_ register frame was empty, not the current one. So the
>> unwind info technically is still wrong. I think you realize that, and
>> the kernel unwinder won't complain, since it's not paranoid about
>> validating accesses to stacked registers. But still, the unwind info
>> is wrong and I'm not terribly comfortable with that.

Keith> I agree, but the end result is benign.

I disagree. A bug is a bug. Relying on implementation-specific
behavior of one particular unwinder doesn't change that.

Keith> Unwind needs a way of saying "this is out of line code, not a
Keith> function, and its state is the same as this ip". But without
Keith> that feature in the unwind spec, this is probably the best
Keith> that we can do. It is a pity that unwind thinks that
Keith> everything is a function and did not consider out of line
Keith> code.

Keith> How about putting the new spinlock code in now so I can
Keith> continue with adding kdb support for debugging hung
Keith> spinlocks? Even with the swapped arg list, any debug data on
Keith> hung spinlocks is better than none at all. I will think some
Keith> more about the unwind descriptors to see if there is any way
Keith> of avoiding the misattribution of the register usage, but the
Keith> worst case is that we live with the swapped argument list.

My experience tells me that if I put in the code now, nobody will work
on a corrected version.

I think it makes sense to start a discussion of extending the unwind
spec to make it easier to accommodate what we're trying to do here. A
similar facility already exists in libunwind for dynamic unwind info
(since runtime function cloning naturally leads to the same issue).

Can you start this discussion?

--david