From: Keith Owens <kaos@ocs.com.au>
To: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.arm.linux.org.uk
Subject: [RFC] Remove section .text.lock
Date: Thu, 27 Dec 2001 15:10:50 +1100 [thread overview]
Message-ID: <11665.1009426250@ocs3.intra.ocs.com.au> (raw)
I plan to stop using section .text.lock for out of line code. Using a
special section for out of line code can generate dangling refernces to
discarded sections, the dangling references are flagged as an error by
binutils 2.11.92.0.12 onwards. See the l-k discussion in thread
http://marc.theaimsgroup.com/?l=linux-kernel&m=100909932003300&w=2
After the above discussion there is general agreement (well, nobody
disagreed) that .text.lock can be replaced with .subsection 1. It
still gives out of line code but without the dangling reference problem
because all references are within the same section. It can even
generate better code, intra section branches can be smaller than inter
section branches.
I am going through 2.4.18-pre1 looking at all references to .text.lock
and converting them, removing vmlinux.lds entries and dead comments at
the same time. Most of the changes are obvious, only i386, ia64, m68k
and arm are really using .text.lock, the rest are copy and paste lines
in vmlinux.lds and are already redundant.
ARM is a problem. It does not use .text.lock for spinlocks (UP only),
instead it uses .text.lock for __do_softirq, __down_failed and friends.
AFAICT this is completely pointless, these routines only occur once so
they are already out of line. .text.lock should be used for the code
that calls these functions and only on the fail path, I see no point in
putting the functions themselves in .text.lock. Can somebody explain
why these arm functions are in section .text.lock instead of normal
.text?
reply other threads:[~2001-12-27 4:11 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=11665.1009426250@ocs3.intra.ocs.com.au \
--to=kaos@ocs.com.au \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®