Hi! I have a problem in the following code (64 bit NOVA 20.08, 3GB RAM, with gdb):
void Component::construct(Env &env) { Rm_connection rm(env);
Region_map_client my_rm(rm.create(0x1400000)); char *_base = env.rm().attach(my_rm.dataspace());
Region_map_client my1_rm(rm.create(0x1000)); env.rm().attach_at(my1_rm.dataspace(), 0x102e000);
log("my create managed dataspace", Hex((addr_t)_base)); }
it return _base [11000000,12400000) and it give error during attach_at() call (which is far from requested address 0x102e000) Error: Uncaught exception of type 'Genode::Region_map::Region_conflict’
Why it is happens? Where this error generated in the NOVA code (or genode NOVA wrapper)?
I assume that I can create 2 RM clients to be able to fill it (attach_to) ds later?
Thanks! Sincerely, Alexander
run file #debug go application via gdb #
set build_components { core init timer lib/ld drivers/uart app/gdb_monitor lib/vfs/pipe noux-pkg/mmaptest }
lappend build_components "lib/gdbserver_platform-$::env(KERNEL)"
build $build_components
create_boot_directory
proc local_heap_default_size {} { return "0x1400000" }
install_config { <config verbose="yes" ld_verbose="yes"> <parent-provides> <service name="ROM" /> <service name="LOG" /> <service name="RM" /> <service name="CPU" /> <service name="PD" /> <service name="IRQ" /> <service name="IO_MEM" /> <service name="IO_PORT" /> </parent-provides> <default-route> <any-service> <parent/> <any-child/> </any-service> </default-route> <default caps="200" /> <start name="timer"> <resource name="RAM" quantum="2M»/> <provides> <service name="Timer"/> </provides> </start> <start name="pc_uart_drv"> <resource name="RAM" quantum="2M" /> <provides> <service name="Uart"/> <service name="Terminal"/> </provides> <config> <policy label_prefix="gdb_monitor" uart="1" /> </config> </start> <start name="gdb_monitor" caps="4800"> <resource name="RAM" quantum="80M" /> <provides> <service name="mmaptest" /> </provides> <config verbose="yes" ld_verbose="yes"> <target name="mmaptest" caps="2800"> <config verbose="yes" ld_verbose="yes" local_heap_default_size="} [local_heap_default_size] {"> <vfs> <dir name="dev"> <log /> </dir> </vfs> <libc stdout="/dev/log" stderr="/dev/log" /> </config> </target> <preserve name="RAM" quantum="50M" /> <vfs> <dir name="dev"> <log/> <terminal/> </dir> <dir name="pipe"> <pipe/> </dir> </vfs> <libc stdout="/dev/log" stderr="/dev/log" pipe="/pipe"/> </config> </start> </config> }
# evaluated by the run tool proc binary_name_gdbserver_platform_lib_so { } { return "gdbserver_platform-$::env(KERNEL).lib.so" }
build_boot_image { core init timer ld.lib.so libc.lib.so vfs.lib.so libm.lib.so pc_uart_drv posix.lib.so stdcxx.lib.so vfs_pipe.lib.so posix.lib.so stdcxx.lib.so vfs_pipe.lib.so gdb_monitor gdbserver_platform.lib.so vfs.lib.so mmaptest }
Hello Alexander,
you enabled 'ld_verbose' in your configuration. Please check if 0x102e000 is already used by any shared library. You may also check the binary with 'genode-x86-readelf -l build/x86_64/debug/test-log'.
Greets
Sorry,
my last tip will not help you further. Now I remember that the region that conflicts with your attachment attempt at 0x102e000 is the linker area, which comprises 256 MiB beginning at the binary link address.
Christian
On Mon, Nov 16, 2020 at 08:49:03 CET, Christian Helmuth wrote:
Hello Alexander,
you enabled 'ld_verbose' in your configuration. Please check if 0x102e000 is already used by any shared library. You may also check the binary with 'genode-x86-readelf -l build/x86_64/debug/test-log'.
Greets
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Hello Christian, thank you for answer!
current map show [init -> gdb_monitor -> mmaptest] 0x40000000 .. 0x4fffffff: stack area [init -> gdb_monitor -> mmaptest] 0x30000 .. 0x1befff: ld.lib.so [init -> gdb_monitor -> mmaptest] 0x10d55000 .. 0x10ffffff: libc.lib.so [init -> gdb_monitor -> mmaptest] 0x10c3a000 .. 0x10d54fff: vfs.lib.so [init -> gdb_monitor -> mmaptest] 0x10bee000 .. 0x10c39fff: libm.lib.so [init -> gdb_monitor -> mmaptest] 0x1030000 .. 0x124bfff: stdcxx.lib.so so, requested range 0x102e000 till 0x102f000 which is BEFORE allocated address related to stdcxx?
I assume that range could be free… while may be it is in use by heap/etc.
anyway, are there ANY way to check what particular addresses are in use, or at least, setup break in GDB to the place where this address generate Regionmap conflict? where are the related places in the genode code?
If I will try to use Libc::valid(addr_t addr) - to verify that it is used, is it always give me correct results?
Sincerely, Alexander
Sorry,
my last tip will not help you further. Now I remember that the region that conflicts with your attachment attempt at 0x102e000 is the linker area, which comprises 256 MiB beginning at the binary link address.
Christian
On Mon, Nov 16, 2020 at 08:49:03 CET, Christian Helmuth wrote:
Hello Alexander,
you enabled 'ld_verbose' in your configuration. Please check if 0x102e000 is already used by any shared library. You may also check the binary with 'genode-x86-readelf -l build/x86_64/debug/test-log'.
Hello Alexander,
On Mon, Nov 16, 2020 at 22:03:49 CET, Alexander Tormasov via users wrote:
current map show [init -> gdb_monitor -> mmaptest] 0x40000000 .. 0x4fffffff: stack area [init -> gdb_monitor -> mmaptest] 0x30000 .. 0x1befff: ld.lib.so [init -> gdb_monitor -> mmaptest] 0x10d55000 .. 0x10ffffff: libc.lib.so [init -> gdb_monitor -> mmaptest] 0x10c3a000 .. 0x10d54fff: vfs.lib.so [init -> gdb_monitor -> mmaptest] 0x10bee000 .. 0x10c39fff: libm.lib.so [init -> gdb_monitor -> mmaptest] 0x1030000 .. 0x124bfff: stdcxx.lib.so so, requested range 0x102e000 till 0x102f000 which is BEFORE allocated address related to stdcxx?
I assume that range could be free… while may be it is in use by heap/etc.
I added information about the linker area to the ldso ld_verbose log with
https://github.com/genodelabs/genode/commit/ec763e25e052a2d61295984942fc41ac...
to reduce the confusion in this regard.
anyway, are there ANY way to check what particular addresses are in use, or at least, setup break in GDB to the place where this address generate Regionmap conflict? where are the related places in the genode code?
The region map does not provide this kind of reflective information. On Genode, we follow the same approach as with Linux mmap(): Just do not expect any fixed address-space layout resp. free address regions. So, there are two options you may choose from.
1) Let env.rm().attach(dataspace) choose a region from your address space that fits your dataspaces one-by-one.
2) If a address region of known size for custom layout requirements is required, create a region map from the RM service with the appropriate size and attach the region-map dataspace with env.rm().attach(). This gives you an appropriate address region and your code must only be parameterized by the base address of this region.
Any other approach of "guessing maybe unused address regions" is designed to fail sooner or later. Imagine libraries that also map dataspaces dynamically for pointer-based data access for example.
If I will try to use Libc::valid(addr_t addr) - to verify that it is used, is it always give me correct results?
I do not know anything about such a function, sorry.
Regards
Hello Christian, thank you for clarification.
Any other approach of "guessing maybe unused address regions" is designed to fail sooner or later. Imagine libraries that also map dataspaces dynamically for pointer-based data access for example.
I try to port «in more correct way» code from golang runtime. It do not assume any particular address, anyway, it actively use mmap as a probe to try to setup so called «arena space» where they make internal allocation. so, they do not try to guess exact layouts, they just have a set of pre-defined addresses where they try to place mapping.
of course, they assume that some of the attempts can fail and try other places… I think that this is relatively safe approach, and I want to have genode mmap with ANON flag works in such a way that I do not need to correct the golang runtime. to check I found abstract mmap test suit and try to apply it. so… partially it works =)
I think that I will stop activities here, allowing free/remap only own ANON mmap allocations, this will be enough for basic golang runtime.
Sincerely, Alexander
seems that I found one reason for the problem. I try to use some mmap test found in internet (and this is not my code, this is standard Unix mmap behaviour, so I do not have any control over it).
As I understand, it try to remap already statically allocated memory (!). Are there any chance to make it correctly? is this allocated in Genode/NOVA as single chunk dataspace? can I try just unmapped part of virtual address space from this ds and map it separately to new ds? Like (where V and v - virtual addresses, D and d - dataspaces attached):
VVVVVV VVVddV DDDDDD => DDDDDD dd
if yes - I probably need to detach() V whole range first and then split it to 3 chunks - two for old ranges to old dataspace «D» and one in the middle to new dataspace «d» to be allocated? seems to be relatively complex process, and I need to find old DS, old range and store all chunks and mappings somewhere… Start thinking of getting rid of remapping for MAP_FIXED support...
just for reference, test contain the following code:
… static char landing_pad[PAGESIZE*2]; ... if (tests[i].flags & MAP_FIXED) mmap_addr = (void *)round_up_page(landing_pad); else mmap_addr = NULL; ... mmap_flags_test(tests[i].filename, mmap_addr, size, tests[i].flags); … static void mmap_flags_test(const char * filename, void * target_addr, unsigned long size, unsigned long flags) { ... addr = mmap(target_addr, bytes, PROT_READ, flags, fd, 0); …
16 нояб. 2020 г., в 11:08, Christian Helmuth christian.helmuth@genode-labs.com написал(а):
Sorry,
my last tip will not help you further. Now I remember that the region that conflicts with your attachment attempt at 0x102e000 is the linker area, which comprises 256 MiB beginning at the binary link address.
Christian
On Mon, Nov 16, 2020 at 08:49:03 CET, Christian Helmuth wrote:
Hello Alexander,
you enabled 'ld_verbose' in your configuration. Please check if 0x102e000 is already used by any shared library. You may also check the binary with 'genode-x86-readelf -l build/x86_64/debug/test-log'.
Greets
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-- Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users