Hi,

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:

http://lists.gnu.org/archive/html/bug-binutils/2004-07/msg00041.html

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 
use.

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.

Comments?

Cheers, Steve