mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Frank Rowand <frowand@mvista.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Karim Yaghmour <karim@opersys.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	LTT-Dev <ltt-dev@shafik.org>,
	frowand@mvista.com
Subject: Re: [ltt-dev] Re: [PATCH] LTT for 2.5.36 9/9: ARM trace support
Date: Thu, 19 Sep 2002 16:27:06 -0700	[thread overview]
Message-ID: <3D8A5D4A.5D7A1442@mvista.com> (raw)
In-Reply-To: <20020920001500.E11763@flint.arm.linux.org.uk>

Russell King wrote:
> 
> You should probably explicitly CC the architecture maintainers with
> these patches.  Generally, there is no guarantee that they'll read
> lkml.
> 
> On Thu, Sep 19, 2002 at 06:35:06PM -0400, Karim Yaghmour wrote:
> > diff -urpN linux-2.5.36/arch/arm/kernel/entry-common.S linux-2.5.36-ltt/arch/arm/kernel/entry-common.S
> > --- linux-2.5.36/arch/arm/kernel/entry-common.S       Tue Sep 17 20:58:42 2002
> > +++ linux-2.5.36-ltt/arch/arm/kernel/entry-common.S   Thu Sep 19 16:29:55 2002
> > @@ -35,6 +35,11 @@ ENTRY(__do_softirq)
> >   * stack.
> >   */
> >  ret_fast_syscall:
> > +#if (CONFIG_TRACE || CONFIG_TRACE_MODULE)
> > +     mov     r7, r0                          @ save returned r0
> > +     bl      SYMBOL_NAME(trace_real_syscall_exit)
> > +     mov     r0, r7
> > +#endif
> 
> This misses the slow syscall exit path.

Thanks, I'll fix that.


> 
> > +#if (CONFIG_TRACE || CONFIG_TRACE_MODULE)
> > +asmlinkage void trace_real_syscall_entry(int scno,struct pt_regs * regs)
> > +{
> > +     int                     depth = 0;
> > +     unsigned long           end_code;
> > +     unsigned long           *fp;                    /* frame pointer */
> > +     unsigned long           lower_bound;
> > +     unsigned long           lr;                     /* link register */
> > +     unsigned long           *prev_fp;
> > +     int                     seek_depth;
> > +     unsigned long           start_code;
> > +     unsigned long           *start_stack;
> > +     trace_syscall_entry     trace_syscall_event;
> > +     unsigned long           upper_bound;
> > +     int                     use_bounds;
> > +     int                     use_depth;
> > +
> > +     trace_syscall_event.syscall_id = (uint8_t)scno;
> > +     trace_syscall_event.address    = instruction_pointer(regs);
> > +
> > +     if (! (user_mode(regs) ))
> > +             goto trace_syscall_end;
> > +
> > +     if (trace_get_config(&use_depth,
> > +                          &use_bounds,
> > +                          &seek_depth,
> > +                          (void*)&lower_bound,
> > +                          (void*)&upper_bound) < 0)
> > +             goto trace_syscall_end;
> > +
> > +     if ((use_depth == 1) || (use_bounds == 1)) {
> > +             fp          = (unsigned long *)regs->ARM_fp;
> 
> You can't rely on FP being set to anything real.  Although the "APCS"
> ABI defines that FP will be either zero or a pointer to a valid frame,
> this isn't always true; a binary built with -fomit-frame-pointer will
> use FP for its own purposes.  This means that there exists the possibility
> for a program without any frames on the stack (although we could be
> many functions deep within the program.)
> 
> Do you care about this?

Yes, but there isn't much we can to about it.  If a program doesn't have
valid frame pointers then we just won't be able to capture a valid
address of where the program made the syscall from.  There are
plenty of paranoia checks to limit the search through the frames (even
with non-existent frame pointers), so this won't be catastrophic.

It looks like I could add one more paranoia check for the initial
value of regs->ARM_fp.


> 
> --
> Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
>              http://www.arm.linux.org.uk/personal/aboutme.html
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev@listserv.shafik.org
> http://www.listserv.shafik.org/listserv/listinfo/ltt-dev


Thanks for the comments!

-Frank
-- 
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc

      reply	other threads:[~2002-09-19 23:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-19 22:35 Karim Yaghmour
2002-09-19 23:15 ` Russell King
2002-09-19 23:27   ` Frank Rowand [this message]

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=3D8A5D4A.5D7A1442@mvista.com \
    --to=frowand@mvista.com \
    --cc=karim@opersys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@shafik.org \
    --cc=rmk@arm.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome