diff options
Diffstat (limited to 'hurd/translator/procfs/jkoenig')
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 173 |
1 files changed, 171 insertions, 2 deletions
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index fc071337..628cb396 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012, 2013, 2014 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -125,7 +125,9 @@ License|/fdl]]."]]"""]] <braunr> but when they do, they do +<a name="self"> # `/proc/self` +</a> ## IRC, freenode, #hurd, around 2010-09 @@ -151,6 +153,8 @@ License|/fdl]]."]]"""]] <antrik> in either case, it can't hurt to bring this up again :-) [[mtab/discussion]], *IRC, freenode, #hurd, 2013-09-07*. +Look at `[glibc]/hurd/lookup-retry.c` for how [[`FS_RETRY_MAGICAL` +lookups|interface/dir_lookup]] work. # root group @@ -348,6 +352,35 @@ Disadvantage is that every program using this needs to be patched. This is used in `[LLVM]/lib/Support/Unix/Path.inc`. +### IRC, OFTC, #debian-hurd, 2013-11-10 + + <mjt> Hello. Does hurd have /proc/self/exe equivalent, to "re-exec myself" + ? + <youpi> no, only argv[0] + <mjt> busybox uses /proc/self/exe by default to re-exec itself when running + one of its applets, or failing that, tries to find it in $PATH. I guess + it doesn't work on hurd... :) + <mjt> and argv0 is unreliable + <youpi> some discussion on the hurd wiki talks about using Dl_info DLInfo + <youpi> which contains DLInfo.dli_fname + <youpi> err, I mean, callling dladdr(&main, &DLInfo); + <youpi> this is kernel-agnostic, provided one uses glibc + <mjt> um. -ldl. nice for static linking + <mjt> gcc t.c -ldl -static + <mjt> ./a.out + <mjt> fname=AVA� �j + <mjt> bah :) + <mjt> (it just prints dli_fname) + <teythoon> :/ + <youpi> ah, yes, that won't work with static linking + <teythoon> fixing /proc/self is on my todo list, it shouldn't be too hard + <youpi> since in that case it's the exec server which sets the process up, + not dl.so + <teythoon> but we do not have the exe link either + <mjt> (the above test run was on linux not on hurd, fwiw_ + <mjt> ) + + # `/proc/[PID]/fd/` ## IRC, freenode, #hurd, 2012-04-24 @@ -436,6 +469,89 @@ Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for `#ifdef __linux__`. +### IRC, freenode, #hurd, 2013-10-03 + + <camm`> what's the equivalent of cat /proc/self/maps on hurd? + <braunr> camm`: for now, /proc/self doesn't work as expected + <camm`> thanks, I just want to get a list of maps and protection status for + a running process -- how? + <braunr> vminfo + <camm`> thanks so much! I'm trying to debug an unexec failure on hurd when + a linker script is present. All works with the default script, but when + the text address is changed, unexec fails, running into a page with no + access in the middle of the executable: 0xc4b000[0x1000] (prot=0, + max_prot=RWX, offs=0xb55000) + <camm`> I get a segfault when trying to read from this page. + <braunr> unexec ? + <camm`> emacs/gcl/maxima/acl2/hol88/axiom use unexec to dump a running + image into a saved executable elf file. + <braunr> what is unexec ? + <braunr> ok looks like a dirty tool + <braunr> camm`: what is segfaulting, unexec or the resulting executable ? + <camm`> unexec opens the file from which the running program was originally + executed, finds its section start addresses, then writes a new file + replacing any data in the old file with possibly modified versions in + running memory. The reverse of 'exec'. + <camm`> the read from running memory delimited by the addresses in the + executable file is hitting a page which has been protected with *no* + access, and is segfaulting. Somehow, when the binary file is loaded, + hurd turning off all rights to this page. + <camm`> let me check the stack location ... + <camm`> ok I think I've got it -- hurd moves the sbrk(0) address away from + the end of .data (as reported by readelf) if the addresses are low, + presumably to avoid running into the stack. + <camm`> starting sbrk(0)!=.data+data_size on hurd + <braunr> i'm not sure there is anything like the heap on the hurd + <braunr> sbrk is probably implemented on top of mmap + <braunr> camm`: hm no, i'm wrong, glibc implements brk and sbrk mostly as + expected, but remapping the area isn't atomic + <braunr> "Now reallocate it with no access allowed" + <braunr> then, there is a call to vm_protect + <braunr> and no error checking + <braunr> ... + <camm`> ok, that's fine, but need to know -- in general there is no + relationship between the address returned by sbrk(0) and the .data + addresses reported by readelf on the file, (hurd only) yes? + <braunr> i don't know about that + <braunr> there should be .. + <camm`> Specific example: readelf -a -> [24] .data PROGBITS + 000f5580 0c4580 000328 00 WA 0 0 32 + <camm`> + <camm`> sbrk(0)->(void *) 0x8021000 + <braunr> camm`: is that on an executable or a shared object ? + <camm`> executable + <braunr> 000f5580 looks very low + <camm`> This is using a linker script. The default setup works just fine. + <camm`> I think it (might) make sense for hurd to silently do this give the + placement of the C stack, but the assumptions behind my algorithm need + changing (perhaps). + <camm`> (I probe in configure the allowable range of __executable_start, + and then choose a value to either ensure a large free signed range around + NULL, or a low data start to maximize heap) + <camm`> braunr: are there any guarantees of sbrk(0)==.data+size without a + linker script? + <braunr> camm`: i'm not sure at all + <braunr> sbrk isn't even posix + <camm`> thanks + + +## IRC, freenode, #hurd, 2014-02-22 + + <ignaker> i'm trying to implement proc/maps + <ignaker> actually I can't well evaluate complexity of tasks. However, I + appreciate your comments + <braunr> the complexity can be roughly estimated from the number of + components involved + <braunr> proc/maps involves procfs, ports, virtual memory, and file systems + <braunr> the naive implementation would merely be associating names to + memory objects, and why not, but a more complete one would go ask file + system servers about them + <braunr> perhaps more + <braunr> although personally i'd go for the naive one because less + dependencies usually means better reliability + <braunr> something similar to task_set_name could do the job + + # `/proc/[PID]/mem` Needed by glibc's `pldd` tool (commit @@ -471,3 +587,56 @@ Needed by glibc's `pldd` tool (commit <braunr> both htop and top seem to have problems report the cpu time <braunr> so i expect the problem to be in procfs + + +# IRC, freenode, #hurd, 2013-10-03 + + <braunr> teythoon: any reason the static variable translator_exists isn't + protected by a lock in procfs/rootdir.c ? + + +## IRC, freenode, #hurd, 2013-10-04 + + <braunr> teythoon: can you tell me why translator_exists isn't protected + from shared access in rootdir_mounts_exists ? + <teythoon> braunr: hm, dunno tbh, I probably thought the race was harmless + enough + <braunr> it probably is + <braunr> settrans -Rg doesn't work on procfs :( + + +# Kernel PID + +## IRC, freenode, #hurd, 2013-09-25 + + <braunr> hm cute, htop layout has become buggy, top just won't start + <teythoon> braunr: make sure your procfs knows the correct kernel pid + <teythoon> # showtrans /proc + <teythoon> /hurd/procfs -c -k 3 + <teythoon> we could have handled this nicer if procfs were integrated + upstream + <teythoon> we should probably just update the default + <braunr> teythoon: mhm + <braunr> $ fsysopts /proc + <braunr> /hurd/procfs --stat-mode=444 --fake-self=1 + <braunr> $ showtrans /proc + <braunr> /hurd/procfs -c + <pinotree> -c == --stat-mode=444 --fake-self=1 + <braunr> better indeed + <braunr> teythoon: thanks + + +## IRC, freenode, #hurd, 2013-10-04 + + <braunr> youpi: i fixed procfs on ironforge and exodar to be started as + procfs -c -k 3 + <braunr> without -k 3, many things as simple as top and uptime won't work + + +## IRC, freenode, #hurd, 2013-10-24 + + <gg0> braunr: i'm using your repo and i can't see cpu percentage in htop + anymore, all zeroes, confirmed? + <braunr> gg0: no + <braunr> gg0: you probably need to reset procfs + <braunr> gg0: settrans /proc /hurd/procfs -c -k 3 |