From owner-freebsd-hackers Thu Jun 28 6:13:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (bingnet2.cc.binghamton.edu [128.226.1.18]) by hub.freebsd.org (Postfix) with ESMTP id 59CF737B403 for ; Thu, 28 Jun 2001 06:13:11 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from opal (cs.binghamton.edu [128.226.123.101]) by bingnet2.cc.binghamton.edu (8.11.4/8.11.4) with ESMTP id f5SDDA500834; Thu, 28 Jun 2001 09:13:10 -0400 (EDT) Date: Thu, 28 Jun 2001 09:13:09 -0400 (EDT) From: Zhihui Zhang X-Sender: zzhang@opal To: Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: trace a library call In-Reply-To: <3B3AF816.3E752607@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG sbrk() is not supported in FreeBSD as a system call (see file vm/vm_mmap.c). However, sbrk(0) can reflect the latest end of the heap. I am interested in how sbrk() interacts with malloc(). I know my question is too specific. Thanks for your answer. I did learn a lesson: mixing abstraction layers is really bad. -Zhihui On Thu, 28 Jun 2001, Terry Lambert wrote: > Zhihui Zhang wrote: > > > > Suppose I write a program that calls sbrk(). How can I trace into the > > function sbrk()? In this particular case, I want to know whether > > sbrk() calls the function in file lib/libstand/sbrk.c or sys/sbrk.S. > > Sometimes it is nice to see what system call is eventually called as well. > > I know dynamic linking may make this hard. But is there a way to do > > this? Thanks. > > sbrk() is a system call, not a library call. It has a > stub that just loads a register with the call ID and > does an INT 0x80. > > You can't "trace into" it, since you are in a user space > program. > > If you want to see how it works, the sources are in /sys; > but all it does is add pages to the end of the address > space, in the heap. > > If you are having problems with it, you are probably using > sbrk() and malloc() in the same program. Don't do that; > malloc() traditionally calls sbrk() to get pages, so you > will have the same effect as trying to use fopen() and > open() in the same program: mainly, that fd manipulation > routines can close/open/etc. fd's out from under file > pointers. In the sbrk() case, there can be attempts to > (re)map pages to regions where they don't really belong. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message