All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Hirst <rhirst@linuxcare.com>
To: Alan Modra <alan@linuxcare.com.au>
Cc: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] parisc64 kernel and ret1 (gr29) setup
Date: Sun, 11 Feb 2001 23:03:30 +0000	[thread overview]
Message-ID: <20010211230330.E1374@linuxcare.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0102112156190.27808-100000@front.linuxcare.com.au>; from alan@linuxcare.com.au on Sun, Feb 11, 2001 at 11:09:32PM +1100

On Sun, Feb 11, 2001 at 11:09:32PM +1100, Alan Modra wrote:
> On Wed, 7 Feb 2001, Richard Hirst wrote:
> 
> > On Tue, Jan 23, 2001 at 01:45:45PM +0000, Richard Hirst wrote:
> > > Presumably r29 needs initialising on every call from entry.S and syscall.S
> > > to C code, but I'm not over confident about that, so I thought I'd let
> > > others see my diff so far.  Comments?
> > 
> > So, I committed that diff, and have been looking at what happens
> > w.r.t. stack frame setup on interrupts.  All we seem to do is to
> > set sp to the top of task_struct (if in a user context), or move
> > sp up by a struct pt_regs if in kernel space.  In both cases,
> > those values are rounded up (TASK_SZ_ALGN and PT_SZ_ALIGN), so
> > there would probably be some space below sp, but should get_stack
> > be explicity allocating a stack frame really?
> 
> This is a bit interesting.  A called procedure can write into certain
> parts of the caller's stack frame, so we should certainly be allocating
> space for these areas.

We now allocate 64 bytes for 32 bit kernels and 128 bytes for 64 bit
kernels.  In fact, (as jsm pointed out to me) the align macro in
arch/parisc/tools/offset.c allowed for a stack frame in its rounding
up already.  It used to always allow only 64 bytes, but I've changed that
to allow 64 or 128 bytes as required.

Richard

  reply	other threads:[~2001-02-11 23:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-21 16:00 [parisc-linux] parisc64 kernel and ret1 (gr29) setup Richard Hirst
2000-12-21 20:57 ` Matthew Wilcox
2000-12-21 20:55   ` Richard Hirst
2001-01-23 13:45 ` Richard Hirst
2001-01-23 14:20   ` Alan Modra
2001-01-23 14:30     ` Matthew Wilcox
2001-01-23 15:43     ` Richard Hirst
2001-02-07 11:18   ` Richard Hirst
2001-02-11 12:09     ` Alan Modra
2001-02-11 23:03       ` Richard Hirst [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-01-23 18:47 Cary Coutant
2001-01-23 21:17 ` Jeffrey A Law

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=20010211230330.E1374@linuxcare.com \
    --to=rhirst@linuxcare.com \
    --cc=alan@linuxcare.com.au \
    --cc=parisc-linux@thepuffingroup.com \
    /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.