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') 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