meissner@osf.org (Michael Meissner) (06/27/90)
In article <451@mtndew.UUCP> friedl@mtndew.UUCP (Stephen J. Friedl) writes: | In article <1990Jun24.001636.20821@scuzzy.uucp>, src@scuzzy.uucp (Source Admin) writes: | > i tried to debug a program that uses the nsl_s (sp?) shared lib | > under ISC 2.0.3 with gdb version 3.4. of course it doesn't work - the program | > get's a SIGTRP in the middle of some lib routine. is this normal/intended or | > a bug in gdb ? | | With shared libraries, the text segment is not writable. This means | that you can't stuff a breakpoint instruction ( INT ? ) there for the | debugger to use, and there is not much you can do about it except | building in a very slow and laborious interpreter. Building an interpreter is not the only possible solution. Another solution if you can remap text pages with shmem or mmap, is to remap the pages into a shared memory segment. If the OS cooperates, the normal ptrace calls would not modify the read-only pages, but modify a copy of the pages. If you have mmap with copy on write, you just use that, and then all pages which do not have breakpoints set will be shared with other clients. Granted you will have to know exactly what your system does in dark corner type cases..... -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Do apple growers tell their kids money doesn't grow on bushes?
andrew@root.co.uk (Andrew Dingwall) (06/29/90)
In article <1990Jun24.001636.20821@scuzzy.uucp> src@scuzzy.uucp (Source Admin) writes: >i tried to debug a program that uses the nsl_s (sp?) shared lib >under ISC 2.0.3 with gdb version 3.4. of course it doesn't work - the program >get's a SIGTRP in the middle of some lib routine. is this normal/intended or >a bug in gdb ? >-- >Heiko Blume c/o Diakite blume@scuzzy.mbx.sub.org FAX (+49 30) 882 50 65 >Kottbusser Damm 28 blume@netmbx.UUCP VOICE (+49 30) 691 88 93 >D-1000 Berlin 61 blume@netmbx.netmbx.de TELEX 184174 intro d This is probably a kernel problem. Breakpoints are often implemented by overwriting the instruction where you want the breakpoint to be with an instruction that will cause a trap of some kind, and then restoring the original instruction afterwards. If a process is to be traced (ie: it has executed a ptrace(0, ...) call) and the text segment is read-only, the kernel marks the text segment for that process as copy-on-write so that, if breakpoints are set, a private writeable copy of the page containing the breakpoint is created. The text of a shared library is (obviously) read-only; the trouble is that not all kernels make the special arrangements described above for shared library text. -- Andrew Dingwall UniSoft Ltd., Saunderson House, Hayne Street, London EC1A 9HH andrew@root.co.uk ..!mcsun!ukc!root44!andrew +44-71-315-6600 FAX:+44-71-315-6622
src@scuzzy.uucp (Source Admin) (07/05/90)
andrew@root.co.uk (Andrew Dingwall) writes: >[.....] >The text of a shared library is (obviously) read-only; the trouble is that >not all kernels make the special arrangements described above for shared >library text. ah, that clears things up. of course the next questions coming to mind are - is this fixed in release 2.2 of ix/386 ? - will they ship a *non-shared* version of the library? -- Heiko Blume c/o Diakite blume@scuzzy.mbx.sub.org FAX (+49 30) 882 50 65 Kottbusser Damm 28 blume@netmbx.UUCP VOICE (+49 30) 691 88 93 D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d "Have you bugged your source today?"