public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Alexander van Heukelum" <heukelum@fastmail.fm>
To: "Sam Ravnborg" <sam@ravnborg.org>
Cc: "Jan Beulich" <jbeulich@novell.com>,
	linux-arch@vger.kernel.org,
	"Alexander van Heukelum" <heukelum@mailshack.com>,
	"Ingo Molnar" <mingo@elte.hu>,
	"LKML" <linux-kernel@vger.kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Cyrill Gorcunov" <gorcunov@gmail.com>
Subject: Re: [PATCH 1/many] PROC macro to annotate functions in assembly files
Date: Thu, 18 Dec 2008 10:23:06 +0100	[thread overview]
Message-ID: <1229592186.26511.1290697613@webmail.messagingengine.com> (raw)
In-Reply-To: <20081217172640.GB5436@uranus.ravnborg.org>

On Wed, 17 Dec 2008 18:26:40 +0100, "Sam Ravnborg" <sam@ravnborg.org>
said:
> On Wed, Dec 17, 2008 at 10:17:54AM +0100, Alexander van Heukelum wrote:
> > Introduce the PROC macro in the generic header file
> > include/linux/linkage.h to annotate functions in assembly
> > files. This is a first step to fully annotate functions
> > (procedures) in .S-files. The PROC macro complements the
> > already existing and being used ENDPROC macro. The generic
> > implementation of PROC is exactly the same as ENTRY.
> > 
> > The goal is to annotate functions, at least those called
> > from C code, with PROC at the beginning and ENDPROC at the
> > end. This is for the benefit of debugging and tracing. It
> > will also allow to introduce a framework to check for
> > nesting problems and missing annotations in a later stage
> > by overriding ENTRY/END and PROC/ENDPROC in architecture-
> > specific code, after the annotation errors have been fixed.
> > 
> > Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> 
> I understand where you are coming from with these.
> But what I see now is:
> 
> ENTRY/END
> PROC/ENDPROC
> KPROBE_ENTRY/KPROBE_END
> 
> And it is not obvious for me reading the comment when I should
> expect which one to be used.
> 
> Could we try to keep it down to two variants?
> And then document when to use which one.

Hi Sam,

Patches to remove KPROBE_ENTRY and KPROBE_END are currently
in the x86-tree.

PROC/ENDPROC should be used around code.

ENTRY/END should be used around objects which are never
executed, like data arrays.

That should be clear enough, I think. The only catch is how
to decide where to use the annotations at all. I have no
complete answer to that. However, in general it would be
good to annotate any object for which an address can be
found in registers, on the stack or in variables. Doubly
so if addresses are within the object but not exactly at
the start of it. This includes assembly functions called
from C (instruction pointer) and arrays.

The macro's are used to align code and data, to identify the
object as code or data and to add object size information to
the debugging info.

Greetings,
    Alexander

> 	Sam
-- 
  Alexander van Heukelum
  heukelum@fastmail.fm

-- 
http://www.fastmail.fm - Access your email from home and the web


  parent reply	other threads:[~2008-12-18  9:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-17  9:17 PROC macro to annotate functions in assembly files Alexander van Heukelum
2008-12-17  9:17 ` [PATCH 1/many] " Alexander van Heukelum
2008-12-17  9:17   ` [PATCH last/many] x86: checking framework for correct use of ENTRY/PROC Alexander van Heukelum
2008-12-17 11:51     ` Cyrill Gorcunov
2008-12-17 12:04       ` Alexander van Heukelum
2008-12-17 14:43         ` Cyrill Gorcunov
2008-12-17 17:26   ` [PATCH 1/many] PROC macro to annotate functions in assembly files Sam Ravnborg
2008-12-17 17:38     ` Cyrill Gorcunov
2008-12-17 18:00       ` Sam Ravnborg
2008-12-17 18:33         ` Cyrill Gorcunov
2008-12-18  9:51         ` Alexander van Heukelum
2008-12-18 10:07           ` Russell King
2008-12-18 11:30             ` Alexander van Heukelum
2008-12-18 10:20           ` Jan Beulich
2008-12-18 12:03           ` Cyrill Gorcunov
2008-12-18 12:40             ` Alexander van Heukelum
2008-12-18 16:05               ` Cyrill Gorcunov
2008-12-18  9:23     ` Alexander van Heukelum [this message]
2008-12-18 12:52     ` Ingo Molnar
2008-12-17 10:53 ` David Howells
2008-12-17 11:12   ` Alexander van Heukelum
2008-12-18 11:44     ` Russell King
2008-12-18 12:35       ` Alexander van Heukelum
2008-12-18 15:53         ` Russell King

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=1229592186.26511.1290697613@webmail.messagingengine.com \
    --to=heukelum@fastmail.fm \
    --cc=akpm@linux-foundation.org \
    --cc=gorcunov@gmail.com \
    --cc=heukelum@mailshack.com \
    --cc=jbeulich@novell.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sam@ravnborg.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox