summaryrefslogtreecommitdiff
path: root/hurd/translator/procfs/jkoenig
diff options
context:
space:
mode:
Diffstat (limited to 'hurd/translator/procfs/jkoenig')
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn173
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