Re: [Linux-ia64] Incorrect unwind data in entry.S

David Mosberger
2001-01-17T01:34:26Z

Hi Cary,

Thanks for your feedback. Here some comments:

>>>>> On Tue, 16 Jan 2001 15:41:25 -0800, Cary Coutant <cary@cup.hp.com> said:

Cary> I apologize for taking so long to respond to this, but I've
Cary> been trying to convince myself that there is a defect in the
Cary> assembly language specification. Specifically, there seems to
Cary> be no directive to specify that a body region has any epilogue
Cary> code, or what the epilogue count should be.

There is, it just has a strange name: ".restore sp" actually generates
an epilogue directive and the (optional) second argument specifies the
epilogue count.

Cary> In the example code quoted below, it's clear to me that the
Cary> first body region (following prologue 1) should have no
Cary> epilogue descriptor, but that the second body region
Cary> (following prologue 2, at label .ret21) should.

Yes, and does indeed due to the ".restore sp" at label "1:".

Cary> It's not, however, clear, whether the epilogue count should be
Cary> 0 (meaning that the epilogue balances only prologue 2) or 1
Cary> (meaning that it balances both prologues). The intent of this
Cary> code seems to be that the epilogue count should be 0, since
Cary> the comment says "pop prologue 2", and execution continues
Cary> with a body region that logically matches the state of the
Cary> first body region.

Cary> There are a couple of problems here, though.

Cary> First, assuming that the epilogue count for body region 2 is
Cary> 0, as intended, the empty prologue 3 region shouldn't be at
Cary> all necessary, since its only purpose is to reconstruct the
Cary> unwind state that existed prior to prologue 2. With the
Cary> proper epilogue count in body region 2, the unwind state for
Cary> body region 3 should follow naturally.

Ah, that's true. That should result in a more optimal encoding.

Cary> Second, nested prologues weren't designed to handle a variable
Cary> frame size. The unwinder assumes that a fixed stack frame size
Cary> applies throughout the procedure. If you're going to change
Cary> the size of your frame, you should copy the previous stack
Cary> pointer (psp) into a local register, and declare a
Cary> variable-size frame with the .vframe directive. You can then
Cary> change the value of sp whenever you like, and the unwinder
Cary> will always know to look in that local register for the value
Cary> of psp.

The kernel unwinder does _not_ assume that the stack size is fixed
throughout the entire procedure. I didn't think the unwind specs
forces that either, but if I'm missing something please let me know.

Cary> If you use .vframe and save psp in a local register, you won't
Cary> have any need for nested prologue regions here.

Since this is kernel exit code, performance is critical and we don't
want to move things around just because of the unwind info. Also, it
could be difficult to find a register that would be available in all
places that these macros are used.

Thanks,

--david