All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alexander van Heukelum" <heukelum@fastmail.fm>
To: Russell King <rmk+lkml@arm.linux.org.uk>,
	Alexander van Heukelum <heukelum@mailshack.com>
Cc: David Howells <dhowells@redhat.com>,
	linux-arch@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	Cyrill Gorcunov <gorcunov@gmail.com>
Subject: Re: PROC macro to annotate functions in assembly files
Date: Thu, 18 Dec 2008 13:35:02 +0100	[thread overview]
Message-ID: <1229603702.27623.1290725827@webmail.messagingengine.com> (raw)
In-Reply-To: <20081218114427.GD10593@flint.arm.linux.org.uk>

On Thu, 18 Dec 2008 11:44:27 +0000, "Russell King"
<rmk+lkml@arm.linux.org.uk> said:
> On Wed, Dec 17, 2008 at 12:12:14PM +0100, Alexander van Heukelum wrote:
> > Yeah, assembly files contain some interesting nesting. In this
> > particular case I think the solution is simple... Just use PROC
> > and ENDPROC around the complete functions, and leave the explicit
> > .global's for the additional entry points.
> 
> I'm sorry, that doesn't work in all cases.
> 
> On ARM with later toolchains, there's additional metadata associated with
> every symbol, and it's beginning to matter getting this right.  That
> metadata includes whether it's a function, and more importantly whether
> the code pointed to by the symbol is Thumb or ARM.
> 
> This leads to:
> 
> ENTRY(__ashldi3)
> ENTRY(__aeabi_llsl)
> 
> ...
> 
> ENDPROC(__ashldi3)
> ENDPROC(__aeabi_llsl)
> 
> and we want both of those symbols to have exactly the same attributes.
> 
> Merely adding a .globl for the second name doesn't do that.  It needs
> .globl, .size, and .type.
> 
> So what you're actually talking about using your approach is enforcing
> the pairing of the existing ENTRY/ENDPROC and open coding everything
> else.

Note that enforcing the pairing will be enabled by ARCH code. Is the
construct you show here (two symbols covering identical code) the only
problem you forsee? I don't want to introduce too many macro's to
handle special cases, but this one should be solved.

> Forgive me if I think this is a backward step.  It certainly seems to
> add some insane restrictions.

Some restrictions are introduced, indeed. And I agree that evading the
checking framework by doing things manually should be avoided.

Greetings,
    Alexander

> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:
-- 
  Alexander van Heukelum
  heukelum@fastmail.fm

-- 
http://www.fastmail.fm - The way an email service should be

  reply	other threads:[~2008-12-18 12:35 UTC|newest]

Thread overview: 25+ 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 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
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 [this message]
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=1229603702.27623.1290725827@webmail.messagingengine.com \
    --to=heukelum@fastmail.fm \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=heukelum@mailshack.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rmk+lkml@arm.linux.org.uk \
    --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 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.