DEFAULT_RELOC and roottask

Alexander Valitov valitov79 at mail.ru
Wed Mar 18 17:21:16 CET 2009



Adam Lackorzynski wrote:
> 
> 
>> 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.
> 
> 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:
> 
>  
>> 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?
> 
> 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
-- 
View this message in context: http://www.nabble.com/DEFAULT_RELOC-and-roottask-tp22556702p22582848.html
Sent from the L4 mailing list archive at Nabble.com.





More information about the l4-hackers mailing list