Re: [RFC] ARM binutils feature churn causing kernel problems

Albert Cahalan
2004-10-08T18:24:38Z

On Fri, 2004-10-08 at 12:36, Paulo Marques wrote:
> Russell King wrote:
> > On Mon, Sep 27, 2004 at 09:03:05PM +0100, Russell King wrote:
> >
> >>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]

The "$" is considered a garbage character by the sanity check.
(same as "\v", "\033", "\xff", and so on)

> 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!)

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

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