Hi I found something intersting, and I wanted to share with all.
I copied the /proc/profile file of host (X86) to a file "my_profile" on the
target system (XScale) and I execute the following command at the target, the
System.map file for the command is the one generated by cross compiling kernel
for XScale (target) itself.
./readprofile -p ./my_profile | sort -nr +2 | head -2
Here is the result ....
./readprofile: profile address out of range. Wrong map file?
5638 sock_wait_for_wmem 22.3730
4186376 _stext 21.7461
637 generic_osync_inode 4.0833
533 sock_kmalloc 3.8071
478 add_breakpoint_arm 2.4896
2473 icmp_send 2.4631
835 sys_wait4 0.9237
73 probe_irq_off 0.7019
57 it_real_fn 0.6786
21 complete_and_exit 0.5250
393 do_exit 0.4962
58 sys_getitimer 0.4833
309 sys_capset 0.4739
37 tvtojiffies 0.4625
52 cpu_idle 0.4194
40 free_uid 0.3571
257 get_branch_address 0.3418
88 prepare_binprm 0.3385
21 iq80310_write_timer 0.3281
81 probe_irq_on 0.3068
-----------------------------------------------------------------
Any comments? using which we could fix this readprofile problem for
XScale/ARM? I think there is a problem in the way, kernel for XScale/ARM is
generating /proc/profile file.
-Thanking you
Shesha
On Tue, 8 Apr 2003, Andy Pfiffer wrote:
> On Tue, 2003-04-08 at 15:41, Shesha@asu.edu wrote:
> > I am running 2.4.18 kernel for ARM. I have one of the boot parameters
> > "profile=2". The size of the /proc/profile file is shown as 16MB. But when I
> > execute "readprofile" the output is ...
> > 0 total nan
> >
> > If I cat the file it just give me a ".". Can anyone suggest what i am doing
> > wrong?
>
> [ I swear I was just talking about this problem with someone else... ]
>
> 1. /proc/profile is a binary file. cat won't show you anything
> meaningful.
>
> 2. the 0 output by readprofile is a problem with the automatic
> byte-order detection heuristic built into the code. Try invoking
> readprofile with the "-n" option, and see if your problem goes away.
>
> FYI: For those that might also run into this, the essence of the problem
> is this piece of code in readprofile.c (fragmented for clarity):
>
> "optNative" is 0.
> "buf" is an unsigned int *.
>
>
> if (!optNative) {
> int entries = len/sizeof(*buf);
> int big = 0,small = 0,i;
> unsigned *p;
>
> for (p = buf+1; p < buf+entries; p++)
> if (*p) {
> if (*p >= 1 << (sizeof(*buf)/2)) big++;
> else small++;
> }
> if (big > small) {
> fprintf(stderr,"Assuming reversed byte order. "
> "Use -n to force native byte order.\n");
> <snipped>
> .
> .
> .
> }
> }
>
> Based on my read of the code, "big" will be incremented if *p >= 4,
> otherwise "small" will be incremented. I can't see how this would ever
> detect the byte order...
>
> Werner proposed this as a solution, but it could still fail to correctly
> detect the byteorder (although with much less frequency):
>
>
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
