summaryrefslogtreecommitdiff
path: root/hurd/translator/procfs
diff options
context:
space:
mode:
Diffstat (limited to 'hurd/translator/procfs')
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn82
1 files changed, 82 insertions, 0 deletions
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
+
+ <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
+
+
# `/proc/[PID]/mem`
Needed by glibc's `pldd` tool (commit
@@ -471,3 +537,19 @@ 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 :(