Re: Weird output from pmap

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

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