Re: [PATCH v2 07/11] s390: Hook s390 into OSABI mechanism

["Ulrich Weigand" <uweigand@de.ibm.com>]

Philipp Rudo wrote:

> > All of that *except* the sigtramp unwinder is OS-independent.  In fact,
> > if move the prolog-based sniffer to common code, you'll see that you no
> > longer need to export various internal routines from s390-tdep.c to
> > s390-linux-tdep.c.
> > 
> > This may require swapping the order of the stub and the sigtramp unwinder,
> > but that should be harmless.  In the end you should have this sequence:
> > 
> > - first, in common code, announce all the DWARF-based unwinders
> > - then, in Linux ABI code, announce the sigtramp unwinder
> > - finally, back in common code, announce all the fallback unwinders
> 
> That's not true.  At least for the kernel the unwinders (except the DWARF-based)
> failed and I had to write my own one.  Especially the fact that the kernel has 
> multiple stack locations and no distinct 'End of Stack' caused problems.
> 
> However if I go with your approach and add my unwinder in the kernel ABI code
> as default, i.e. that it always catches the call, it should work.  But that
> won't be nice code.  That's why I moved them to the Linux ABI.

That's surprising, I would have thought the prolog parser generic enough
to handle kernel code as well (and it really has to be anyway, since you
install the s390_skip_prologue callback in generic code ...).

I agree that there may be some special cases.  About the issues you mention:

- By "multiple stack locations" I assume you refer to the interrupt stack
  vs. the regular per-task kernel stacks?  I agree that we need kernel-
  specific code to switch between the two.  But that should simply be
  the equivalent to the user-space signal stack handling, so you'll install
  a sniffer in the kernel-specific code that detects the frame where you
  need to *switch* stacks.  All the normal frames should be handled fine
  by the standard prolog-parser code.

- End-of-stack detection is always a bit hit-and-miss with the prolog
  parser, and uses heuristics anyway.  If you need to tweak those a
  bit so they work well for kernel code, I'd hope (without having seen
  the code) that it should be possible to simply update the generic
  code to handle both.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com