Date: Thu, 28 Jun 2001 09:41:50 -0400 (EDT) From: Zhihui Zhang <zzhang@cs.binghamton.edu> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: trace a library call Message-ID: <Pine.SOL.4.21.0106280938360.22558-100000@opal> In-Reply-To: <Pine.SOL.4.21.0106280909080.21305-100000@opal>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.4.21.0106280938360.22558-100000>