Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!ukc!stc!root44!andrew
From: andrew@root.co.uk (Andrew Dingwall)
Newsgroups: comp.unix.questions
Subject: Re: SysV.3 shared libs - not debugable ?!
Keywords: SysV.3 shared libraries
Message-ID: <2310@root44.co.uk>
Date: 29 Jun 90 15:31:44 GMT
References: <2835@uniol.UUCP> <13159@smoke.BRL.MIL> <1990Jun24.001636.20821@scuzzy.uucp>
Reply-To: andrew@root.co.uk (Andrew Dingwall)
Organization: UniSoft Ltd, London, England
Lines: 26

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