DEFAULT_RELOC and roottask
Adam Lackorzynski
adam at os.inf.tu-dresden.de
Thu Mar 19 22:57:50 CET 2009
On Wed Mar 18, 2009 at 09:21:16 -0700, Alexander Valitov wrote:
> 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).
Sounds like ELF loading :)
> 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?
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).
> >
> >
>
> 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.
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:
> >
> >
> >> 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:
Thanks, will do.
Adam
--
Adam adam at os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/
More information about the l4-hackers
mailing list