Re: Weird output from pmap

["Erik Niessen" <erik.niessen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4738 bytes --]

Hi Ralf,

Thanks for your response.
This is the output from readelf
 mipsel-linux-readelf -S helloworldmips
There are 29 section headers, starting at offset 0x1290:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk
Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0
0  0
  [ 1] .interp           PROGBITS        004000f4 0000f4 000014 00   A  0
0  1
  [ 2] .reginfo          MIPS_REGINFO    00400108 000108 000018 18   A  0
0  4
  [ 3] .dynamic          DYNAMIC         00400120 000120 0000f8 08   A  6
0  4
  [ 4] .hash             HASH            00400218 000218 0000b4 04   A  5
0  4
  [ 5] .dynsym           DYNSYM          004002cc 0002cc 0001a0 10   A  6
1  4
  [ 6] .dynstr           STRTAB          0040046c 00046c 00011b 00   A  0
0  1
  [ 7] .gnu.version      VERSYM          00400588 000588 000034 02   A  5
0  2
  [ 8] .gnu.version_r    VERNEED         004005bc 0005bc 000020 00   A  6
1  4
  [ 9] .init             PROGBITS        004005dc 0005dc 000088 00  AX  0
0  4
  [10] .text             PROGBITS        00400670 000670 0004c0 00  AX  0
0 16
  [11] .MIPS.stubs       PROGBITS        00400b30 000b30 000070 00  AX  0
0  4
  [12] .fini             PROGBITS        00400ba0 000ba0 000058 00  AX  0
0  4
  [13] .rodata           PROGBITS        00400c00 000c00 0000f0 00   A  0
0 16
  [14] .eh_frame         PROGBITS        00400cf0 000cf0 000004 00   A  0
0  4
  [15] .ctors            PROGBITS        10000000 001000 000008 00  WA  0
0  4
  [16] .dtors            PROGBITS        10000008 001008 000008 00  WA  0
0  4
  [17] .jcr              PROGBITS        10000010 001010 000004 00  WA  0
0  4
  [18] .data             PROGBITS        10000020 001020 000030 00  WA  0
0 16
  [19] .rld_map          PROGBITS        10000050 001050 000004 00  WA  0
0  4
  [20] .got              PROGBITS        10000060 001060 00004c 04 WAp  0
0 16
  [21] .sbss             NOBITS          100000ac 0010ac 000000 00 WAp  0
0  1
  [22] .bss              NOBITS          100000b0 0010ac 000020 00  WA  0
0 16
  [23] .comment          PROGBITS        00000000 0010ac 00005a 00      0
0  1
  [24] .pdr              PROGBITS        00000000 001108 0000a0 00      0
0  4
  [25] .mdebug.abi32     PROGBITS        00000000 0011a8 000000 00      0
0  1
  [26] .shstrtab         STRTAB          00000000 0011a8 0000e5 00      0
0  1
  [27] .symtab           SYMTAB          00000000 001718 000500 10     28
51  4
  [28] .strtab           STRTAB          00000000 001c18 00023f 00      0
0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

This one tells me that the bss is writable?? Can you giev me a direction
where the problem is??

Cheers,


On 9/7/06, Ralf Baechle <ralf@linux-mips.org> wrote:
>
> On Tue, Sep 05, 2006 at 08:55:18AM +0200, Erik Niessen wrote:
>
> > /helloworldmips(86)
> > 00400000 (4 KB)        r-xp (00:0a 33243002)   linux/test/helloworldmips
> > 10000000 (4 KB)        rw-p (00:0a 33243002)   linux/test/helloworldmips
> > 10001000 (4 KB)        rwxp (00:00 0)        [heap]
> > 2aaa8000 (20 KB)       r-xp (00:07 1795853)
> > /lib/ld-uClibc-0.9.27.so<http://uclibc-0.9.27.so/>
> > 2aaad000 (4 KB)        rw-p (00:00 0)
> > 2aaed000 (4 KB)        rw-p (00:07 1795853)  /lib/ld-
> > uClibc-0.9.27.so<http://uclibc-0.9.27.so/>
> > 2aaee000 (48 KB)       r-xp (00:07 1795861)  /lib/libgcc_s.so.1
> > 2aafa000 (252 KB)      ---p (00:00 0)
> > 2ab39000 (4 KB)        rw-p (00:07 1795861)  /lib/libgcc_s.so.1
> > 2ab3a000 (368 KB)      r-xp (00:07 1795855)  /lib/libuClibc-0.9.27.so
> > 2ab96000 (256 KB)      ---p (00:00 0)
> > 2abd6000 (8 KB)        rw-p (00:07 1795855)  /lib/libuClibc- 0.9.27.so
> > 2abd8000 (16 KB)       rw-p (00:00 0)
> > 7fd49000 (84 KB)       rwxp (00:00 0)        [stack]
> > mapped:   1076 KB writable/private: 128 KB shared: 0 KB
> >
> > It seems that the bss segments of the shared libs are protected and
> mapped
> > to the zero page. I don't see this
> > when I run this on a linux pc. I have the following questions:
> > - Why is this segment protected? Accessing results in a seg fault.
>
> Protecting a bss segment doesn't make sense.
>
> The address and the "---p" flags make me suspect your executable might
> actually be wrong, so I suggest you check the binary with something like
> readelf -S.
>
> > - Why is it so big (252k/256K)?
> > - How much memory is physically allocated for this segment?
>
> None at this stage - the actuall allocation would happen lazily when
> a page is touched first which of course doesn't ever happen in your
> case.
>
>   Ralf
>

[-- Attachment #2: Type: text/html, Size: 10015 bytes --]