The ARM binutils seems to be in a problematical state at the moment.It has recently had a "bug" fixed where ARM specific "mapping symbols"were not generated in ELF objects. These "mapping symbols" have namessuch as "$a" and "$d".

The unfortunate problem is that "$a" nearly always corresponds withthe same address as the name of a function - and since none of thekernel knows about these "mapping symbols" we see backtraces whicheffectively say:

[<address>] ($a+0xfoo/0xbar) from [<address>] ($a+0xfoo/0xbar)

in other words, the kallsyms table and the symbol tables from kernelmodules are next to useless because it invariably decodes all addressesto functions named "$a".

While the binutils people have (we believe) fixed "ld" to ignorethese symbols when decoding to a function name, "nm" reveals thesesymbols.

It may be true that this will cause a lot of stuff which parsesELF objects to break, and I'm not going to debate whether the wholeidea is a good one or bad. However, what are peoples (Rusty's inparticular) to adding yet more ARM binutils specific hacks to thekernel to work around these continuing problems?

My major worry is that ARM ELF format will end up having soo manyextra "features" that the Linux kernel, if it's going to continuesupporting ARM, will need a fair amount of code to make all thesefeatures "work" as expected.