From owner-freebsd-hackers Thu Jun 28 6:41:55 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 11BD037B409 for ; Thu, 28 Jun 2001 06:41:52 -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 f5SDfo516288; Thu, 28 Jun 2001 09:41:50 -0400 (EDT) Date: Thu, 28 Jun 2001 09:41:50 -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: 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 I am sorry. It turns out when the argument is zero, sbrk() does not enter into the kernel. If it does, it will return not supported. -Zhihui On Thu, 28 Jun 2001, Zhihui Zhang wrote: > > 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