ARM binutils feature churn causing kernel problems

From loooking at the gcc and binutils lists it seems codesourcery is pushing

Quoted 1 line

From loooking at the gcc and binutils lists it seems codesourcery is pushing

through all the ARM EABI bullshit. Maybe we can persuade hjl to keep it out of his bintuils release? So far we've been served far better with them on Linux anyway..

From loooking at the gcc and binutils lists it seems codesourcery is pushing through all the ARM EABI bullshit. Maybe we can persuade hjl to keep it out of his bintuils release? So far we've been served far better with them on Linux anyway..

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

Russell,

kernel/module.c line 1912

Quoted 6 lines · Russell King

+ * This ignores the intensely annoying "mapping symbols" found
+ * in ARM ELF files: $a, $t and $d.
+ */

kernel/module.c +3 -0

+static inline int is_arm_mapping_symbol(const char *str)
+{
+	return str[0] == '$' && strchr("atd", str[1]) && str[2] == '\0';

str[2] can be '\0' or '.', since a mapping symbol can also be $[atd].<any> (because binutils doesn't like to generate duplicate local labels).

Russell, I thought about not including any symbol which is not of form "[A-Za-z0-9_]+" in kallsyms, for all archs: you are not the only one with weird-ass symbols. Is it that you want these mapping symbols in /proc/kallsyms but ignored in backtraces, or you don't need them in kallsyms altogether?

Thanks,
Rusty.

Quoted 6 lines · Rusty Russell <rusty <at> rustcorp.com.au> writes:

Russell, I thought about not including any symbol which is not of form "[A-Za-z0-9_]+" in kallsyms, for all archs: you are not the only one with weird-ass symbols. Is it that you want these mapping symbols in /proc/kallsyms but ignored in backtraces, or you don't need them in kallsyms altogether?

Quoted 2 lines

Thanks,
Rusty.

Mapping symbols will always be encoded with STB_LOCAL and STT_NOTYPE. I would have thought it unlikely that the kernel would ever want to report against any symbol with those attributes and they could all be dropped on that basis.

Quoted 11 lines · Richard Earnshaw

Quoted 8 lines · Rusty Russell <rusty <at> rustcorp.com.au> writes:

Russell, I thought about not including any symbol which is not of form "[A-Za-z0-9_]+" in kallsyms, for all archs: you are not the only one with weird-ass symbols. Is it that you want these mapping symbols in /proc/kallsyms but ignored in backtraces, or you don't need them in kallsyms altogether?

Thanks,
Rusty.

Quoted 4 lines

Mapping symbols will always be encoded with STB_LOCAL and STT_NOTYPE. I would have thought it unlikely that the kernel would ever want to report against any symbol with those attributes and they could all be dropped on that basis.

(Richard - your mailer appears to have dropped people from the CC: list...)

How about this patch? Is there a better way to parse the 'nm' output to achieve the same as your suggestion above?

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x *.orig -x *.rej orig/kernel/module.c linux/kernel/module.c

kernel/module.c +4 -0

@@ -1923,6 +1923,10 @@ static const char *get_ksymbol(struct mo
 		if (mod->symtab[i].st_shndx == SHN_UNDEF)
 			continue;
 
+		if (ELF_ST_BIND(mod->symtab[i].st_info) == STB_LOCAL
+		    && ELF_ST_TYPE(mod->symtab[i].st_info) == STT_NOTYPE)
+			continue;
+
 		/* We ignore unnamed symbols: they're uninformative
 		 * and inserted at a whim. */
 		if (mod->symtab[i].st_value <= addr

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x *.orig -x *.rej orig/scripts/kallsyms.c linux/scripts/kallsyms.c

scripts/kallsyms.c +11 -0

@@ -32,6 +32,17 @@ usage(void)
 	exit(1);
 }
 
+/*
+ * This ignores the intensely annoying "mapping symbols" found
+ * in ARM ELF files: $a, $t and $d.
+ */
+static inline int
+is_arm_mapping_symbol(const char *str)
+{
+	return str[0] == '$' && strchr("atd", str[1]) &&
+	       (str[2] == '\0' || str[2] == '.');
+}
+
 static int
 read_symbol(FILE *in, struct sym_entry *s)
 {

Quoted 30 lines · Russell King

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x *.orig -x *.rej orig/scripts/kallsyms.c linux/scripts/kallsyms.c

scripts/kallsyms.c +13 -1

@@ -32,6 +32,17 @@ usage(void)
 	exit(1);
 }
 
+/*
+ * This ignores the intensely annoying "mapping symbols" found
+ * in ARM ELF files: $a, $t and $d.
+ */
+static inline int
+is_arm_mapping_symbol(const char *str)
+{
+	return str[0] == '$' && strchr("atd", str[1]) &&
+	       (str[2] == '\0' || str[2] == '.');
+}
+
 static int
 read_symbol(FILE *in, struct sym_entry *s)
 {

@@ -56,7 +67,8 @@ read_symbol(FILE *in, struct sym_entry *
 		_sinittext = s->addr;
 	else if (strcmp(str, "_einittext") == 0)
 		_einittext = s->addr;
-	else if (toupper(s->type) == 'A' || toupper(s->type) == 'U')
+	else if (toupper(s->type) == 'A' || toupper(s->type) == 'U' ||
+		 is_arm_mapping_symbol(str))
 		return -1;
 

scripts/kallsyms.c read_symbol(FILE *in, struct sym_entry * · line 74

Quoted 1 line

scripts/kallsyms.c +0 -0

 	s->sym = strdup(str);

Why don't you pass s to is_arm_mapping_symbol and have it do the same thing as you've done in get_ksymbol?

----------------------------------------------------------------
This e-mail message is intended for the addressee(s) only and may contain information that is the property of, and/or subject to a confidentiality agreement between the intended recipient(s), their organisation and/or the ARM Group of Companies. If you are not an

intended recipient of this e-mail message, you should not read, copy, forward or otherwise distribute or further disclose the information in it; misuse of the contents of this e-mail message may violate various laws in your state, country or jurisdiction. If you have received this e-mail message in error, please contact the originator of this e-mail message via e-mail and delete all copies of this message from your computer or network, thank you.
----------------------------------------------------------------

Quoted 2 lines

Why don't you pass s to is_arm_mapping_symbol and have it do the same thing as you've done in get_ksymbol?

"sym_entry" is not an ELF symtab structure - it's a parsed version of the `nm' output, and as such does not contain the symbol type nor binding information.

Quoted 4 lines

----------------------------------------------------------------
This e-mail message is intended for the addressee(s) only and may contain information that is the property of, and/or subject to a
...

Does this apply to your message? It would appear that third parties subscribed to linux-kernel are not allowed to read your messages because they're not an "intended recipient" !

Quoted 3 lines · Russell King

Quoted 2 lines

Why don't you pass s to is_arm_mapping_symbol and have it do the same thing as you've done in get_ksymbol?

Quoted 4 lines

"sym_entry" is not an ELF symtab structure - it's a parsed version of the `nm' output, and as such does not contain the symbol type nor binding information.

Ah. That makes the question in your previous message make more sense then. What options do you pass to nm?

Looking at the output of nm -fsysv shows that currently the mapping symbols are being incorrectly typed (the EABI requires them to be STT_NOTYPE, but the previous ELF specification -- not supported by GNU utils -- required them to be typed by the data they addressed. I'll submit a patch for that shortly).

Quoted 5 lines · Richard Earnshaw

Looking at the output of nm -fsysv shows that currently the mapping symbols are being incorrectly typed (the EABI requires them to be STT_NOTYPE, but the previous ELF specification -- not supported by GNU utils -- required them to be typed by the data they addressed. I'll submit a patch for that shortly).

Ugg - in that case, we need to go with the "match the name" version until these changes in binutils have matured (== 2 or 3 years time.)

Quoted 8 lines · Russell King

Quoted 5 lines · Richard Earnshaw

Looking at the output of nm -fsysv shows that currently the mapping symbols are being incorrectly typed (the EABI requires them to be STT_NOTYPE, but the previous ELF specification -- not supported by GNU utils -- required them to be typed by the data they addressed. I'll submit a patch for that shortly).

Quoted 2 lines

Ugg - in that case, we need to go with the "match the name" version until these changes in binutils have matured (== 2 or 3 years time.)

Why does the Linux ARM ABI have to have any relation to the ARM EABI? The PowerPC has had two different ABIs for years, and it's not caused us any trouble. Can't we just leave the behaviour of binutils alone when configured for an arm-linux target, and put all feature churn into an arm-eabi target?

Why does the Linux ARM ABI have to have any relation to the ARM EABI? The PowerPC has had two different ABIs for years, and it's not caused us any trouble. Can't we just leave the behaviour of binutils alone when configured for an arm-linux target, and put all feature churn into an arm-eabi target?

Quoted 5 lines · Richard Earnshaw

Quoted 3 lines · Russell King

Quoted 2 lines

Why don't you pass s to is_arm_mapping_symbol and have it do the same thing as you've done in get_ksymbol?

Quoted 7 lines

Quoted 4 lines

"sym_entry" is not an ELF symtab structure - it's a parsed version of the `nm' output, and as such does not contain the symbol type nor binding information.

Ah. That makes the question in your previous message make more sense then. What options do you pass to nm?

Only -n.

Quoted 5 lines

Looking at the output of nm -fsysv shows that currently the mapping symbols are being incorrectly typed (the EABI requires them to be STT_NOTYPE, but the previous ELF specification -- not supported by GNU utils -- required them to be typed by the data they addressed. I'll submit a patch for that shortly).

Ugg - in that case, we need to go with the "match the name" version until these changes in binutils have matured (== 2 or 3 years time.)

Quoted 2 lines · Richard Earnshaw

Why don't you pass s to is_arm_mapping_symbol and have it do the same thing as you've done in get_ksymbol?

"sym_entry" is not an ELF symtab structure - it's a parsed version of the `nm' output, and as such does not contain the symbol type nor binding information.

Quoted 5 lines · Russell King

Quoted 2 lines · Richard Earnshaw

Why don't you pass s to is_arm_mapping_symbol and have it do the same thing as you've done in get_ksymbol?

Quoted 3 lines

"sym_entry" is not an ELF symtab structure - it's a parsed version of the `nm' output, and as such does not contain the symbol type nor binding information.

I believe that Paulo (CC'd) ended up with a patch which included the actual type information in /proc/kallsyms. Paulo, what's the status of that patch?

The patch by Russel King seems ok to me, although I prefer Rusty's idea of not using any symbol that is not in the form "[A-Za-z0-9_]+". We just need to check if there are any real world users of these "weird" symbols.

Quoted 1 line · Paulo Marques

The patch by Russel King seems ok to me, although I prefer Rusty's idea of not using any symbol that is not in the form "[A-Za-z0-9_]+". We just need to check if there are any real world users of these "weird" symbols.

This may filter out too much - we have symbols starting with a '.' on ARM, particularly used in some of the assembly code, which are useful to be decoded back to names, such as ".bug".

However, including "." means that names like "__func__.0" also get included, which is probably a bad thing. So, maybe it needs to be

[A-Za-z0-9_\.][A-Za-z0-9_]*

Quoted 11 lines · Richard Earnshaw

Quoted 8 lines · Rusty Russell <rusty <at> rustcorp.com.au> writes:

Russell, I thought about not including any symbol which is not of form "[A-Za-z0-9_]+" in kallsyms, for all archs: you are not the only one with weird-ass symbols. Is it that you want these mapping symbols in /proc/kallsyms but ignored in backtraces, or you don't need them in kallsyms altogether?

Thanks,
Rusty.

Quoted 4 lines

Mapping symbols will always be encoded with STB_LOCAL and STT_NOTYPE. I would have thought it unlikely that the kernel would ever want to report against any symbol with those attributes and they could all be dropped on that basis.

(Richard - your mailer appears to have dropped people from the CC: list...)

How about this patch? Is there a better way to parse the 'nm' output to achieve the same as your suggestion above?

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x *.orig -x *.rej orig/kernel/module.c linux/kernel/module.c

kernel/module.c +4 -0

@@ -1923,6 +1923,10 @@ static const char *get_ksymbol(struct mo
 		if (mod->symtab[i].st_shndx == SHN_UNDEF)
 			continue;
 
+		if (ELF_ST_BIND(mod->symtab[i].st_info) == STB_LOCAL
+		    && ELF_ST_TYPE(mod->symtab[i].st_info) == STT_NOTYPE)
+			continue;
+
 		/* We ignore unnamed symbols: they're uninformative
 		 * and inserted at a whim. */
 		if (mod->symtab[i].st_value <= addr

diff -up -x BitKeeper -x ChangeSet -x SCCS -x _xlk -x *.orig -x *.rej orig/scripts/kallsyms.c linux/scripts/kallsyms.c

scripts/kallsyms.c +11 -0

@@ -32,6 +32,17 @@ usage(void)
 	exit(1);
 }
 
+/*
+ * This ignores the intensely annoying "mapping symbols" found
+ * in ARM ELF files: $a, $t and $d.
+ */
+static inline int
+is_arm_mapping_symbol(const char *str)
+{
+	return str[0] == '$' && strchr("atd", str[1]) &&
+	       (str[2] == '\0' || str[2] == '.');
+}
+
 static int
 read_symbol(FILE *in, struct sym_entry *s)
 {

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

Quoted 4 lines · Russell King

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

Ok, another tool which is affected by this is procps:

$ ps alx
Warning: /boot/System.map-2.6.9-rc3 not parseable as a System.map
Warning: /boot/System.map not parseable as a System.map
Warning: /usr/src/linux/System.map has an incorrect kernel version.
F   UID   PID  PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
4     0     1     0  16   0  1244  508 do_sel S    ?          0:01 init [3]

Quoted 8 lines · Russell King

Quoted 4 lines · Russell King

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

Quoted 8 lines

Ok, another tool which is affected by this is procps:

$ ps alx
Warning: /boot/System.map-2.6.9-rc3 not parseable as a System.map
Warning: /boot/System.map not parseable as a System.map
Warning: /usr/src/linux/System.map has an incorrect kernel version.
F   UID   PID  PPID PRI  NI   VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
4     0     1     0  16   0  1244  508 do_sel S    ?          0:01 init [3]

ps is reading System.map probably because reading /proc/<pid>/wchan directly was very slow. It used to take an average of 1.3ms (on a P4 2.8GHz) and now it takes less than 0.5us (that is miliseconds and microseconds!)

If this is the case, then after the changes to kallsyms go in, procps could start using wchan directly and avoid reading the System.map altogether.

....

No, the /proc/*/wchan file is supposed to be used. For some reason, stat() is failing. Here is the code:

  // next try the Linux 2.5.xx method
  if(!stat("/proc/self/wchan", &sbuf)){
    use_wchan_file = 1; // hack
    return 0;
  }

See what these commands tell you:

strace -o data -e trace=stat ps alx >> /dev/null ; grep self data stat /proc/self/wchan
stat /proc/$$/wchan
stat /proc/self/
stat /proc/self

Quoted 1 line

If this is the case, then after the changes to kallsyms go in, procps could start using wchan directly and avoid reading the System.map altogether.

Here's an idea: if both name and number were provided at the same time and I could get notified when a module is loaded or unloaded, then I could cache the number-to-name translation.

Ok, here's the latest version of the patch, fixing all presently known issues with ARM binutils post 2.11.90 by changing the kernel to suit.

Yes, it sounds like the wrong thing to do, but shrug.

---

All ARM binutils versions post 2.11.90 contains an extra "feature" which interferes with the kernel in various ways - extra "mapping symbols" in the ELF symbol table '$a', '$t' and '$d'. This causes two problems:

1. Since '$a' symbols have the same value as function names, this causes anything which uses the kallsyms infrastructure to report wrong values.
2. programs which parse System.map do not expect symbols to start with '$'.

Signed-off-by Russell King <[email protected]>

===== kernel/module.c 1.120 vs edited =====

kernel/module.c +14 -2

@@ -1903,6 +1903,16 @@
 }
 
 #ifdef CONFIG_KALLSYMS
+/*
+ * This ignores the intensely annoying "mapping symbols" found
+ * in ARM ELF files: $a, $t and $d.
+ */
+static inline int is_arm_mapping_symbol(const char *str)
+{
+	return str[0] == '$' && strchr("atd", str[1]) 
+	       && (str[2] == '\0' || str[2] == '.');
+}
+
 static const char *get_ksymbol(struct module *mod,
 			       unsigned long addr,
 			       unsigned long *size,

@@ -1927,11 +1937,13 @@
 		 * and inserted at a whim. */
 		if (mod->symtab[i].st_value <= addr
 		    && mod->symtab[i].st_value > mod->symtab[best].st_value
-		    && *(mod->strtab + mod->symtab[i].st_name) != '\0' )
+		    && *(mod->strtab + mod->symtab[i].st_name) != '\0'
+		    && !is_arm_mapping_symbol(mod->strtab + mod->symtab[i].st_name))
 			best = i;
 		if (mod->symtab[i].st_value > addr
 		    && mod->symtab[i].st_value < nextval
-		    && *(mod->strtab + mod->symtab[i].st_name) != '\0')
+		    && *(mod->strtab + mod->symtab[i].st_name) != '\0'
+		    && !is_arm_mapping_symbol(mod->strtab + mod->symtab[i].st_name))
 			nextval = mod->symtab[i].st_value;
 	}
 

===== scripts/kallsyms.c 1.12 vs edited =====

scripts/kallsyms.c +13 -1

@@ -32,6 +32,17 @@
 	exit(1);
 }
 
+/*
+ * This ignores the intensely annoying "mapping symbols" found
+ * in ARM ELF files: $a, $t and $d.
+ */
+static inline int
+is_arm_mapping_symbol(const char *str)
+{
+	return str[0] == '$' && strchr("atd", str[1])
+	       && (str[2] == '\0' || str[2] == '.');
+}
+
 static int
 read_symbol(FILE *in, struct sym_entry *s)
 {

@@ -56,7 +67,8 @@
 		_sinittext = s->addr;
 	else if (strcmp(str, "_einittext") == 0)
 		_einittext = s->addr;
-	else if (toupper(s->type) == 'A' || toupper(s->type) == 'U')
+	else if (toupper(s->type) == 'A' || toupper(s->type) == 'U' ||
+		 is_arm_mapping_symbol(str))
 		return -1;
 
 	s->sym = strdup(str);

===== scripts/mksysmap 1.4 vs edited =====

scripts/mksysmap +1 -1

@@ -40,5 +40,5 @@
 # so we just ignore them to let readprofile continue to work.
 # (At least sparc64 has __crc_ in the middle).
 
-$NM -n $1 | grep -v '\( [aUw] \)\|\(__crc_\)' > $2
+$NM -n $1 | grep -v '\( [aUw] \)\|\(__crc_\)\|\( \$[adt]\)' > $2
 

Signature · 5 lines

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core