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
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 27 Dec 2001 15:10:50 +1100
Message-ID: <11665.1009426250@ocs3.intra.ocs.com.au>
Sender: linux-kernel-owner@vger.kernel.org

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?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/