Re: load-store emulation with SIGSEGV (gate.S bug?)

Re: load-store emulation with SIGSEGV (gate.S bug?)

[Jeffrey William Lake]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

After some investigation I discovered that a "flushrs" at the start of my
signal handler cured the problem.

Looking at "arch/ia64/kernel/gate.S" revealed that a "cover" is used to
get the registers onto the backing store (commented as such several
times), but by my understanding there is enough scope from the instruction
description that they may be cached. Therefore, should gate.S include a
"flushrs" as well or, for performance reasons be left for the user to
decide?

Re: load-store emulation with SIGSEGV (gate.S bug?)

[Keith Owens]

On 17 Oct 2003 15:26:13 -0000, 
Jeffrey William Lake <lakes@lakes.plus.com> wrote:
>After some investigation I discovered that a "flushrs" at the start of my
>signal handler cured the problem.
>
>Looking at "arch/ia64/kernel/gate.S" revealed that a "cover" is used to
>get the registers onto the backing store (commented as such several
>times), but by my understanding there is enough scope from the instruction
>description that they may be cached.

cover only marks the current frame (r32+) as dirty.  It does not write
the dirty registers out to backing store, that is left to RSE to do at
its leisure.  flushrs forces RSE to write the dirty registers out to
memory.

>Therefore, should gate.S include a
>"flushrs" as well or, for performance reasons be left for the user to
>decide?

Probably best left for the user to decide.  The majority of signal
handlers will not require the registers to be flushed.

Re: load-store emulation with SIGSEGV (gate.S bug?)

[David Mosberger]

>>>>> On 17 Oct 2003 15:26:13 -0000, Jeffrey William Lake <lakes@lakes.plus.com> said:

  Jeffrey> After some investigation I discovered that a "flushrs" at
  Jeffrey> the start of my signal handler cured the problem.

  Jeffrey> Looking at "arch/ia64/kernel/gate.S" revealed that a
  Jeffrey> "cover" is used to get the registers onto the backing store
  Jeffrey> (commented as such several times), but by my understanding
  Jeffrey> there is enough scope from the instruction description that
  Jeffrey> they may be cached. Therefore, should gate.S include a
  Jeffrey> "flushrs" as well or, for performance reasons be left for
  Jeffrey> the user to decide?

There is no need to have a flushrs in gate.S.  If you want to access
the register-backing store in memory, you'll need to do a flushrs
anyhow.  BTW: you could use libunwind to access the registers, as that
would save you from having to know such details.  But of course it may
be a bit overkill (probably not too bad, though).

	--david