Hi,
I try to run l4con examples with grub script given in ./l4/pkg/l4con/doc/menu.lst (slightly modified/updated). The menu.lst starts con_demo1, con_demo2 and con_demo3. Boot process gives me this error:
#0d: loading "/boot/test/con_demo1" from [026ce000-0277262c] to [00800000-008250b5][00826000-0083d000] entry at 00068370 via trampoline page code symbols at [3a30e000-3a313000] (20kB), lines at [3a2fd000-3a30e000] (68kB) #0e: loading "/boot/test/con_demo2" from [02773000-02804e08] to [00800000-00815d11] Roottask: cannot load binary because address at 00800000 not free loaded module: [02773000-02804e08) /boot/test/con_demo2 overlaps with: [00800000-00826000) #0d con_demo1
I found that Makefile specifies DEFAULT_RELOC_x86 variable as: DEFAULT_RELOC_x86 = 0x00800000 As a result -Ttext=0x800000 option is added to 'ld' invocation options. I thought that is the root of problem and commented variable, but It didn't help. Build system started to use default DEFAULT_RELOC value 0x01000000 from ./l4/mk/binary.inc and roottask gives the same error with new 0x01000000 address.
1. I thought that DEFAULT_RELOC specifies virtual address not a physical one. Am I right?
2. If answer to my first question is 'yes'. Why in this case roottask relocates a code? It is strange as roottask operates with physical memory addresses.
3. When am I supposed to specify DEFAULT_RELOC variable? In which situation?
4. Why do we need the relocation performed by root task at all? Why can't we just use appropriate mapping to addresses where GRUB loaded ELF modules? Each server starts in its own virtual address space, so I think it's possible. Why was it done that way? What is the problem with described approach (without relocation)?
5. I've been playing around with L4Env,L4Linux and stuff for a while but have never faced with mentioned problem. Are there anything special about the way how con_demo1,2,3 are built? I mean Root task relocates another modules to the next free 4K aligned address but con_demo1,2,3 modules to some exact address. Why does it happened?
6. There is ./l4/pkg/l4con/examples/Makeconf file with link addresses specification. But according to "Building Infrastructure for DROPS (BID) Specification" only Makeconf.local file is included into generated Makefile from project directories. Why is it where?
Best Regards, Alexander Valitov
Hi,
On Tue Mar 17, 2009 at 03:56:42 -0700, Alexander Valitov wrote:
I try to run l4con examples with grub script given in ./l4/pkg/l4con/doc/menu.lst (slightly modified/updated). The menu.lst starts con_demo1, con_demo2 and con_demo3. Boot process gives me this error:
#0d: loading "/boot/test/con_demo1" from [026ce000-0277262c] to [00800000-008250b5][00826000-0083d000] entry at 00068370 via trampoline page code symbols at [3a30e000-3a313000] (20kB), lines at [3a2fd000-3a30e000] (68kB) #0e: loading "/boot/test/con_demo2" from [02773000-02804e08] to [00800000-00815d11] Roottask: cannot load binary because address at 00800000 not free loaded module: [02773000-02804e08) /boot/test/con_demo2 overlaps with: [00800000-00826000) #0d con_demo1
I found that Makefile specifies DEFAULT_RELOC_x86 variable as: DEFAULT_RELOC_x86 = 0x00800000 As a result -Ttext=0x800000 option is added to 'ld' invocation options. I thought that is the root of problem and commented variable, but It didn't help. Build system started to use default DEFAULT_RELOC value 0x01000000 from ./l4/mk/binary.inc and roottask gives the same error with new 0x01000000 address.
Correct observation.
- I thought that DEFAULT_RELOC specifies virtual address not a physical
one. Am I right?
It's a virtual but it doesn't matter actually because programs started by roottask are started identity mapped.
- If answer to my first question is 'yes'. Why in this case roottask
relocates a code? It is strange as roottask operates with physical memory addresses.
What do you mean with relocate? roottask does not do any relocation of the binaries it loads.
- When am I supposed to specify DEFAULT_RELOC variable? In which situation?
All programs started by roottask directly need a unique area they run in. This is controlled by specifying a link-address, it's called RELOC in the Makefiles, and moreover DEFAULT_RELOC because one can overwrite with own settings using a STATIC file in pkg/.
- Why do we need the relocation performed by root task at all? Why can't we
just use appropriate mapping to addresses where GRUB loaded ELF modules? Each server starts in its own virtual address space, so I think it's possible. Why was it done that way? What is the problem with described approach (without relocation)?
This is the way roottask is doing things, it's not particular nice but keeps that paging logic rather simple (poor argument, you may state). Actually, that what you want is done by the loader, i.e. the loader can run programs linked to anywhere. So the recipe is to use the loader to start any program that does not need to be started by roottask directly.
- I've been playing around with L4Env,L4Linux and stuff for a while but
have never faced with mentioned problem. Are there anything special about the way how con_demo1,2,3 are built? I mean Root task relocates another modules to the next free 4K aligned address but con_demo1,2,3 modules to some exact address. Why does it happened?
All those programs are linked to a specific address which need to be distinct when run with other programs. If you look for a free area in what roottask dumps you can put your program in there and it should start. But as already said just use the loader to launch those and it should just work.
- There is ./l4/pkg/l4con/examples/Makeconf file with link addresses
specification. But according to "Building Infrastructure for DROPS (BID) Specification" only Makeconf.local file is included into generated Makefile from project directories. Why is it where?
Don't know it's not from me, looks like it's not used at all :)
Adam
Adam Lackorzynski wrote:
- If answer to my first question is 'yes'. Why in this case roottask
relocates a code? It is strange as roottask operates with physical memory addresses.
What do you mean with relocate? roottask does not do any relocation of the binaries it loads.
By using 'to relocate' I meant 'to move' or 'to change location'. I didn't imply any run-time linkage or fixups for Non Position Independent Code which use relocation entries from special ELF file section. But it doesn't matter anyway as you already answered to this question. Let me summarize. If I get it right then Root task reads ELF's 'Program headers' and moves module's segments with 'LOAD' type to 'VirtAddr' address logging allocated memory (for future check). If FileSiz and MemSiz values for some segment are not equal (e.g. if bss section with NOBITS type is contained within segment) then root task allocates MemSiz amount of memory and copies only FileSiz bytes (MemSiz >= FileSiz is always true for correct ELF).
Root task also copies 'symbols' and 'lines' to some location: symbols at [0eb10000-0eb66000] (344kB), lines at [0eaf6000-0eb10000] (104kB)
1. Can they be used with jdb? Are there any doc regarding it?
Adam Lackorzynski wrote:
This is the way roottask is doing things, it's not particular nice but keeps that paging logic rather simple (poor argument, you may state).
2. Does roottask maps all required pages for each task before it starts the task? Is it possible at all?
If it does then roottask don't have to remember memory layout for each task (for case of page fault) and could just terminate each task who triggered page fault (task has already had all that it needs thus behaves wrong). I think in this case it's not much harder to use modules as they were loaded by GRUB, the only difficulty that I see is that .bss sections must be additionally allocated somewhere else.
I mean Root task relocates another modules to the next free 4K aligned address but con_demo1,2,3 modules to some exact address.
OK. I was completely wrong here.
Adam Lackorzynski wrote:
- There is ./l4/pkg/l4con/examples/Makeconf file with link addresses
specification. But according to "Building Infrastructure for DROPS (BID) Specification" only Makeconf.local file is included into generated Makefile from project directories. Why is it where?
Don't know it's not from me, looks like it's not used at all :)
3. (Just a thought) Maybe it is wise to remove unused file from repository? Also I guess it's a good idea to change ./l4/pkg/l4con/doc/menu.lst into something like this:
kernel /boot/test/bootstrap modaddr 0x02000000 module /boot/test/main -nokdb -serial_esc module /boot/test/sigma0 module /boot/test/roottask task modname "bmodfs" attached 6 modules module /boot/test/names module /boot/test/log module /boot/test/l4io module /boot/test/dm_phys --isa=0x00800000 module /boot/test/simple_ts -t 300 module /boot/test/l4con module /boot/test/bmodfs module /boot/test/con_demo1 module /boot/test/con_demo2 module /boot/test/con_demo3 module /boot/test/con_evdemo module /boot/test/con_txtdemo module /boot/test/con_exit_demo module /boot/test/loader --fprov=BMODFS con_demo1 con_demo2 con_demo3 \ con_evdemo con_txtdemo con_exit_demo vbeset 0x117
Best Regards, Alexander Valitov
On Wed Mar 18, 2009 at 09:21:16 -0700, Alexander Valitov wrote:
Adam Lackorzynski wrote:
- If answer to my first question is 'yes'. Why in this case roottask
relocates a code? It is strange as roottask operates with physical memory addresses.
What do you mean with relocate? roottask does not do any relocation of the binaries it loads.
By using 'to relocate' I meant 'to move' or 'to change location'. I didn't imply any run-time linkage or fixups for Non Position Independent Code which use relocation entries from special ELF file section. But it doesn't matter anyway as you already answered to this question. Let me summarize. If I get it right then Root task reads ELF's 'Program headers' and moves module's segments with 'LOAD' type to 'VirtAddr' address logging allocated memory (for future check). If FileSiz and MemSiz values for some segment are not equal (e.g. if bss section with NOBITS type is contained within segment) then root task allocates MemSiz amount of memory and copies only FileSiz bytes (MemSiz >= FileSiz is always true for correct ELF).
Sounds like ELF loading :)
Root task also copies 'symbols' and 'lines' to some location: symbols at [0eb10000-0eb66000] (344kB), lines at [0eaf6000-0eb10000] (104kB)
- Can they be used with jdb? Are there any doc regarding it?
Yes, that's the reason. There's a jdb manual available on the Fiasco site. Symbols are use for backtrace and in disassembly, e.g.
Adam Lackorzynski wrote:
This is the way roottask is doing things, it's not particular nice but keeps that paging logic rather simple (poor argument, you may state).
- Does roottask maps all required pages for each task before it starts the
task? Is it possible at all?
If it does then roottask don't have to remember memory layout for each task (for case of page fault) and could just terminate each task who triggered page fault (task has already had all that it needs thus behaves wrong). I think in this case it's not much harder to use modules as they were loaded by GRUB, the only difficulty that I see is that .bss sections must be additionally allocated somewhere else.
Another point is to control the usage of physical memory which might not be the layout GRUB leaves behind. There are quite a few things which can be done differently.
Adam Lackorzynski wrote:
- There is ./l4/pkg/l4con/examples/Makeconf file with link addresses
specification. But according to "Building Infrastructure for DROPS (BID) Specification" only Makeconf.local file is included into generated Makefile from project directories. Why is it where?
Don't know it's not from me, looks like it's not used at all :)
- (Just a thought) Maybe it is wise to remove unused file from repository?
Also I guess it's a good idea to change ./l4/pkg/l4con/doc/menu.lst into something like this:
Thanks, will do.
Adam
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Alexander Valitov