Subject: ARM mapping symbols in the kernel
To: None <email@example.com, firstname.lastname@example.org>
From: Steve Woodford <email@example.com>
Date: 06/19/2005 12:14:45
While bringing up the kernel on an ARM-based board recently, I ran into a
problem cause by binutils-2.15. In a nutshell, this version of binutils
adds ARM mapping symbols to every arm32 object file.
For the uninitiated, ARM mapping symbols provide a way to mark arm32 and
thumb instructions, and also data embedded within .text. The ARM ELF
spec requires these special symbols exist for various reasons, not least
of which is accurate disassembly.
The symbols take the form "$a" for arm32 insns, "$t" for thumb insns, and
"$d" for data. The trouble starts when they get into the kernel's symbol
table. In many cases these symbols take the same value as regular
symbols (there are multiple instances of these mapping symbols), this
leads to mass confusion in ddb(9), for example. The result is that
nearly all calls to db_printsym() end up displaying the raw address
instead of the correct symbol+offset. This is because db_printsym() does
a forward lookup on the address which returns, say "$a", then does a
reverse lookup with "$a" to compare the address. This almost always
fails since the reverse lookup always returns the address of the *first*
instance of "$a".
Also, it's no surprise to note that since binutils-2.15 was imported,
there have been quite a few commits of the form "Bump SYMTAB_SPACE" for
our arm32 ports...
There is a thread on this subject here:
I'd be inclined to ignore the patch mentioned in that message, based on
Richard Earnshaw's comments further down the thread. But the fact
remains that we need to address this if ddb(9) on arm32 is to be of any
As a local work-around, I have added some code in
kern_ksyms.c:addsymtab() which skips mapping symbols if __arm__ is
defined. But I'd prefer something like the objcopy(1) option mentioned
in the above thread.