[U-Boot] [PATCH] sandbox: Add improved RAM simulation

[Matthias Weisser]

Am 01.11.2011 21:10, schrieb Mike Frysinger:
> On Tuesday 01 November 2011 15:01:55 Matthias Weisser wrote:
>> Am 01.11.2011 19:52, schrieb Mike Frysinger:
>>> On Tuesday 01 November 2011 14:37:24 Matthias Weisser wrote:
>>>> I don't know the memory layout strategies for all the Linux/Unix variant
>>>> out there. But typically text/bss/data is in the lower address range
>>>> (some megs above 0) and in the upper range (right under kernel space)
>>>> there is space used for stack and shared objects. Even with ASLR the
>>>> address I used in the patch should be mappable.
>>>
>>> relying on any address layout behavior is doomed to fail.  and in this
>>> case, it's unnecessary.  so let's not bother.
>>
>> Accepted but not convinced :-) As the address passed to mmap is only a
>> hint it will not fail. But I will remove the hint in V2 of the patch.
> 
> by "fail" i meant "relying on the address being the same all the time".  not 
> "mmap returned MAP_FAILED".
> -mike

I just implemented it as suggested. One thing I observed now is that an
unhinted mmap now returns an address > 4GB (on my x86_64 machine) which
is directly mapped under the shared object address range.

$ cat /proc/9150/maps
...
7f0e6f09b000-7f0e7709b000 rw-p 00000000 00:00 0        # <u-boot RAM
7f0e7709b000-7f0e77225000 r-xp 00000000 08:02 1198174  # libc
...

After applying Simons md patch I can now successfully md the 128MBytes
of simulated RAM. If I use an "virtual" address close to the end of this
area:

=>md 7ffff80
md 7ffff80
07ffff80: 00000000 00000000 00000000 00000000    ................
07ffff90: 00000000 00000000 00000000 00000000    ................
07ffffa0: 00000000 00000000 00000000 00000000    ................
07ffffb0: 00000000 00000000 00000000 00000000    ................
07ffffc0: 00000000 00000000 00000000 00000000    ................
07ffffd0: 00000000 00000000 00000000 00000000    ................
07ffffe0: 00000000 00000000 00000000 00000000    ................
07fffff0: 00000000 00000000 00000000 00000000    ................
08000000: 464c457f 00010102 00000000 00000000    .ELF............
08000010: 003e0003 00000001 0001f010 00000000    ..>.............
08000020: 00000040 00000000 0018ed28 00000000    @.......(.......
08000030: 00000000 00380040 0040000a 00460047    .... at .8...@.G.F.
08000040: 00000006 00000005 00000040 00000000    ........ at .......
08000050: 00000040 00000000 00000040 00000000    @....... at .......
08000060: 00000230 00000000 00000230 00000000    0.......0.......
08000070: 00000008 00000000 00000003 00000004    ................

So, as you can see, dumping to far is not faulting. It just dumps (in
this case) the first bytes of my local libc.

Regards
Matthias