dynamic loading broken because mmap() no longer works with a backing file about nanos HOT 13 CLOSED

@convolvatron
May you clarify some moments.
I wrote manifest, I think i did make mistake in this file. Could you check?

cat ./hw.manifest
(
#64 bit elf to boot from host
children:(kernel:(contents:(host:stage3/stage3))
#user program
hw:(contents:(host:examples/hw))
libc.so:(contents:(host:/lib/x86_64-linux-gnu/libc.so.6))
ld-linux:(contents:(host:/lib64/ld-linux-x86-64.so.2))
)
# filesystem path to elf for kernel to run
program:/hw
fault:t
arguments:[webg poppy]
environment:(USER:bobby PWD:/)
)

ldd ./hw
linux-vdso.so.1 => (0x00007ffe3cddf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6b56470000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6b5683a000)

If this file is correct. The program was fail on the init_service_new_stack -> runloop call... Any ideas?
program never call mmap

from nanos.

the only thing that strikes me about your example is that the locations of the shared libraries in the uniboot filesystem probably aren't where ld.so is going to look for them, they should be identical in path with the locations on the source.

Tijoy is working on tooling to make this easier, but its a bit of a chicken-and-egg right now, so you'll have to build out the direction structure using the 'children' tag.

in order to make progress it would be helpful to look at the RIP of the crash and try to look in up in the source (likely unix/exec.c), otherwise its basically impossible for anyone to say anything about your crash without trying to replicate it. given where the project is, there really isn't any assumption that things are supposed to 'just work'....so try things, when they fail figure out why, and fix them.

from nanos.

@convolvatron
It looks that you right. The fail is in call resolve_path...
Can you clarify your thought about path, or write small manifest example .

from nanos.

ok. its probably for ld.so itself. it would probably help a lot to fix up the error handling as well

i was just about to do a little writeup for Tijoy...but briefly the filesystem is embedded into a graph data store. each file is a node on the graph. each node is a map from keys to values, each key label describes an edge, and each value can be another tuple node, or a flat string buffer.

the filesystem schema in this datastore allows arbitrary properties to be associated with each file (things like user, group, mode bits, etc that we haven't put in yet)

there are a few keys that the filesystem uses...the one in this case is 'children'.

every directory has a children property, which points to another node..which contains
the children. every key in the children map is a filename, and the edge points to the
node corresponding to that file.

so to set the foo property for /a/b from root you need to

(children:(a:(children:(b:(foo:3))))

it almost exactly like JSON with no quotes around the tags, and parens instead of curly braces

from nanos.

thank a lot. I will try

from nanos.

@convolvatron
According to your letter I tried check where reading is completed and relation between reading and mmap. But for my point of view this is another issue.
from file mamp.c in line if (!(b = table_find(f->n, sym(contents)))) we go to
file runtime/table.c (function table_find)

if (!(b = table_find(f->n, sym(contents))))
This is absent record with key whicj we try found.
(gdb) p k&(t->buckets-1)
$3 = 3
(gdb) p t->entries[0]
$4 = (entry) 0x0
(gdb) p t->entries[1]
$5 = (entry) 0x20000043000
(gdb) p t->entries[2]
$6 = (entry) 0x0
(gdb) p t->entries[3]
$7 = (entry) 0x0

also I added more logs

syscall brk
syscall uname
syscall access
syscall access
syscall open
try open file /etc/ld.so.cache
open /etc/ld.so.cache - not found
syscall open
try open file /lib/x86_64-linux-gnu/tls/libc.so.6
open /lib/x86_64-linux-gnu/tls/libc.so.6 - not found
syscall stat
syscall open
try open file /lib/x86_64-linux-gnu/libc.so.6
open completed
syscall read
contents_read
readcomplete
syscall fstat
syscall mmap
mmap
mmap table not found
syscall close
General protection fault

It looks like we forgot to add a correct field value, or we tried to find the incorrect sym.

My manifest file:

(
    #64 bit elf to boot from host
    children:(kernel:(contents:(host:stage3/stage3))
              #user program
              hw:(contents:(host:examples/hw))
              lib:(children:(x86_64-linux-gnu:(children:(
                                                            libc.so.6:(contents:(host:/lib/x86_64-linux-gnu/libc.so.6))
                                                            )
                                                        )
                                      )
                            )
              lib64:(children:(
                                ld-linux-x86-64.so.2:(contents:(host:/lib64/ld-linux-x86-64.so.2))
                             )
                    )              
             )
             
    # filesystem path to elf for kernel to run
    program:/hw
    fault:t
    arguments:[webg poppy]
    environment:(USER:bobby PWD:/)
)

from nanos.

you're missing some context here. 'contents' gets translated by mkfs into 'extents', which is used by the filesystem to keep track of which blocks on disk contain the file

please use filesystem_read_entire to get the contents of the file from mmap.

from nanos.

note I have branches where a get on sym(contents) does the right thing under the covers, but its not in yet

from nanos.

@convolvatron
Can you tell me where i can obtain tuple for table_find(fs->files, t)) ? Is it present in file struct? Because this information needs for call filesystem_read_entire

from nanos.

The second idea is call filesystem_read_entire in the function which open dependent .so files (Still not found this place, where read this section from elf).

from nanos.

if you look at the open() syscall, its resolved and put in the variable 'n', and stashed
in the closure for contents_read. i think its quite reasonable to promote it to being
a member of the file structure, since any fd can have metadata.

your second idea isn't really feasible, as the code that opens the dependent .so files
is the ld.so dynamic loader, which runs in userspace, and we dont modify

from nanos.

fixed pending will's mmap pr and eric's read overrun pr

from nanos.

safe to close @convolvatron ?

from nanos.