All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suparna Bhattacharya <suparna@in.ibm.com>
To: Andi Kleen <ak@muc.de>
Cc: prasanna@in.ibm.com, linux-kernel@vger.kernel.org,
	torvalds@osdl.org, akpm@osdl.org
Subject: Re: [1/3] kprobes-func-args-268-rc3.patch
Date: Thu, 5 Aug 2004 19:03:48 +0530	[thread overview]
Message-ID: <20040805133348.GA4471@in.ibm.com> (raw)
In-Reply-To: <20040805125423.GA63682@muc.de>

On Thu, Aug 05, 2004 at 02:54:23PM +0200, Andi Kleen wrote:
> On Thu, Aug 05, 2004 at 05:54:31PM +0530, Suparna Bhattacharya wrote:
> > > I think you misunderstood Linus' suggestion.  The problem with
> > > modifying arguments on the stack frame is always there because the C
> > > ABI allows it. One suggested solution was to use a second function
> > 
> > I did realise that it is the ABI which allows this, but I thought
> > that the only situation in which we know gcc to actually clobber
> > arguments from the callee in practice is for tailcall optimization. 
> 
> It just breaks the most common workaround. 

Just curious, do you know if other cases/optimizations where the
callee clobbers arguments on stack ?

> 
> > I'm not sure if that can be guaranteed and yes saving bytes from
> > stack would avoid the problem totally (hence the comment) and make
> > it less tied to expected innards of the compiler. The only issue 
> > with that is deciding the maximum number of arguments so it is 
> > generic enough. 
> 
> 64bytes, aka 16 arguments seem far enough.

OK, is there is consensus on this ? 
We'd have to make the code check for stack boundary etc and probably 
compare and copy back only if there has been a change.

> 
> > > call that passes the arguments again to get a private copy. But the
> > > compiler's tail call optimization could sabotate that when you a
> > > are not careful.
> > > 
> > > That's all quite hackish and compiler dependent. I would suggest an 
> > > assembly wrapper that copies the arguments when !CONFIG_REGPARM.
> > > Just assume the function doesn't have more than a fixed number
> > > of arguments, that should be good enough.
> > > 
> > > This way you avoid any subtle compiler dependencies.
> > > With CONFIG_REGPARM it's enough to just save/restore pt_regs,
> > > which kprobes will do anyways.
> > > >  
> > 
> > Even with CONFIG_REGPARM, if you have a large 
> > number of arguments for example, is spill over into stack 
> > a possibility ?
> 
> Yes. For more than three (Linux uses -mregparm=3) 
> Also varargs arguments will be always on the stack I think.

Right, so making the copy dependent on !CONFIG_REGPARM wouldn't
make sense would it ?

Regards
Suparna

-- 
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India


  reply	other threads:[~2004-08-05 13:26 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2pMJz-13N-9@gated-at.bofh.it>
2004-08-05 11:09 ` [1/3] kprobes-func-args-268-rc3.patch Andi Kleen
2004-08-05 12:24   ` Suparna Bhattacharya
2004-08-05 12:54     ` Andi Kleen
2004-08-05 13:33       ` Suparna Bhattacharya [this message]
2004-08-05 13:51         ` Andi Kleen
2004-08-05 15:05           ` Suparna Bhattacharya
2004-08-05  9:24 Prasanna S Panchamukhi

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=20040805133348.GA4471@in.ibm.com \
    --to=suparna@in.ibm.com \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prasanna@in.ibm.com \
    --cc=torvalds@osdl.org \
    /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.