[lkml]   [2004]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC] ARM binutils feature churn causing kernel problems

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 names
such as "$a" and "$d".

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

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

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

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

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

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

Russell King
Linux kernel 2.6 ARM Linux -
maintainer of: 2.6 PCMCIA -
2.6 Serial core
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:06    [W:0.115 / U:39.044 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site