From 47e4d194dc36adfcfd2577fa4630c9fcded005d3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 27 Oct 2013 19:15:06 +0100 Subject: IRC. --- hurd/translator/procfs/jkoenig/discussion.mdwn | 82 ++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) (limited to 'hurd/translator/procfs/jkoenig/discussion.mdwn') diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index fc071337..018db7b2 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -436,6 +436,72 @@ Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for `#ifdef __linux__`. +### IRC, freenode, #hurd, 2013-10-03 + + what's the equivalent of cat /proc/self/maps on hurd? + camm`: for now, /proc/self doesn't work as expected + thanks, I just want to get a list of maps and protection status for + a running process -- how? + vminfo + 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) + I get a segfault when trying to read from this page. + unexec ? + emacs/gcl/maxima/acl2/hol88/axiom use unexec to dump a running + image into a saved executable elf file. + what is unexec ? + ok looks like a dirty tool + camm`: what is segfaulting, unexec or the resulting executable ? + 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'. + 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. + let me check the stack location ... + 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. + starting sbrk(0)!=.data+data_size on hurd + i'm not sure there is anything like the heap on the hurd + sbrk is probably implemented on top of mmap + camm`: hm no, i'm wrong, glibc implements brk and sbrk mostly as + expected, but remapping the area isn't atomic + "Now reallocate it with no access allowed" + then, there is a call to vm_protect + and no error checking + ... + 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? + i don't know about that + there should be .. + Specific example: readelf -a -> [24] .data PROGBITS + 000f5580 0c4580 000328 00 WA 0 0 32 + + sbrk(0)->(void *) 0x8021000 + camm`: is that on an executable or a shared object ? + executable + 000f5580 looks very low + This is using a linker script. The default setup works just fine. + 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). + (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) + braunr: are there any guarantees of sbrk(0)==.data+size without a + linker script? + camm`: i'm not sure at all + sbrk isn't even posix + thanks + + # `/proc/[PID]/mem` Needed by glibc's `pldd` tool (commit @@ -471,3 +537,19 @@ Needed by glibc's `pldd` tool (commit both htop and top seem to have problems report the cpu time so i expect the problem to be in procfs + + +# IRC, freenode, #hurd, 2013-10-03 + + teythoon: any reason the static variable translator_exists isn't + protected by a lock in procfs/rootdir.c ? + + +## IRC, freenode, #hurd, 2013-10-04 + + teythoon: can you tell me why translator_exists isn't protected + from shared access in rootdir_mounts_exists ? + braunr: hm, dunno tbh, I probably thought the race was harmless + enough + it probably is + settrans -Rg doesn't work on procfs :( -- cgit v1.2.3 From 7343a9815c3bce0b1c0235eec4d43d9cbbb54ccd Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 28 Oct 2013 00:09:49 +0100 Subject: hurd/translator/procfs/jkoenig/discussion: Kernel PID. --- hurd/translator/mtab/discussion.mdwn | 5 +--- hurd/translator/proc.mdwn | 24 ----------------- hurd/translator/procfs/jkoenig/discussion.mdwn | 37 ++++++++++++++++++++++++++ 3 files changed, 38 insertions(+), 28 deletions(-) (limited to 'hurd/translator/procfs/jkoenig/discussion.mdwn') diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index f9f52a3b..2e7999f5 100644 --- a/hurd/translator/mtab/discussion.mdwn +++ b/hurd/translator/mtab/discussion.mdwn @@ -2476,11 +2476,8 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. teythoon: if (control && control->pi.port_right == fsys) that's the filtering i was previously talking about - oh please don't name global variables "path" ... - youpi: i fixed procfs on ironforge and exodar to be started as - procfs -c -k 3 - without -k 3, many things as simple as top and uptime won't work + oh please don't name global variables "path" ... ### IRC, freenode, #hurd, 2013-10-06 diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn index 75bfb8fd..b3b5e703 100644 --- a/hurd/translator/proc.mdwn +++ b/hurd/translator/proc.mdwn @@ -66,30 +66,6 @@ It is stated by `/hurd/init`. ## IRC, freenode, #hurd, 2013-09-25 so nice to finally see proc in top :) - hm cute, htop layout has become buggy, top just won't start - braunr: make sure your procfs knows the correct kernel pid - # showtrans /proc - /hurd/procfs -c -k 3 - we could have handled this nicer if procfs were integrated - upstream - we should probably just update the default - teythoon: mhm - $ fsysopts /proc - /hurd/procfs --stat-mode=444 --fake-self=1 - $ showtrans /proc - /hurd/procfs -c - -c == --stat-mode=444 --fake-self=1 - better indeed - teythoon: thanks - - -## IRC, freenode, #hurd, 2013-10-24 - - braunr: i'm using your repo and i can't see cpu percentage in htop - anymore, all zeroes, confirmed? - gg0: no - gg0: you probably need to reset procfs - gg0: settrans /proc /hurd/procfs -c -k 3 # Process Discovery diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 018db7b2..87ff0248 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -553,3 +553,40 @@ Needed by glibc's `pldd` tool (commit enough it probably is settrans -Rg doesn't work on procfs :( + + +# Kernel PID + +## IRC, freenode, #hurd, 2013-09-25 + + hm cute, htop layout has become buggy, top just won't start + braunr: make sure your procfs knows the correct kernel pid + # showtrans /proc + /hurd/procfs -c -k 3 + we could have handled this nicer if procfs were integrated + upstream + we should probably just update the default + teythoon: mhm + $ fsysopts /proc + /hurd/procfs --stat-mode=444 --fake-self=1 + $ showtrans /proc + /hurd/procfs -c + -c == --stat-mode=444 --fake-self=1 + better indeed + teythoon: thanks + + +## IRC, freenode, #hurd, 2013-10-04 + + youpi: i fixed procfs on ironforge and exodar to be started as + procfs -c -k 3 + without -k 3, many things as simple as top and uptime won't work + + +## IRC, freenode, #hurd, 2013-10-24 + + braunr: i'm using your repo and i can't see cpu percentage in htop + anymore, all zeroes, confirmed? + gg0: no + gg0: you probably need to reset procfs + gg0: settrans /proc /hurd/procfs -c -k 3 -- cgit v1.2.3