Re: sbrk vs mmap (FreeBSD)


T.M. Sommers wrote:
Chewy509 wrote:

I'm having some issues with rewriting a simple malloc() function to be
with FreeBSD (AMD64). This is part of porting an application from Linux
to FreeBSD.

After pulling my hair out for a while, I've found that the sbrk()
system call just returns "45 - Operation Not Supported" error,
irrespective of the parameters passed to it. (I can't locate the actual
kernel source file that does the actual implementation of sbrk(), so a
pointer to the source file would be great - one of the benefits of Open
Source(tm) is having the source, but it's useless if you can't find the
source file your after! j/k).

sbrk() is not part of POSIX, so who knows what it does. I would
suggest looking at the source of malloc() in libc to see what it
does.

The source for the sbrk kernel function is in
/usr/src/sys/kern/vm/vm_mmap.c, and as you found it just returns
an error code. If you disassemble the sbrk() function in libc,
it uses syscall number 0x11, which is called break. The kernel
function used by this syscall is obreak, in .../vm/vm_unix.c.

You really should be using malloc (or mmap, as you mentioned
later), since it is the real, documented, official POSIX memory
allocation interface. It also has the advantage of being portable.

Hi Thomas,

Thanks for the info (esp the source file location). My preferred option
is to use mmap() (as per the FreeBSD kernel maintainers advice), but
can't work why my call is failing... guess I'll hunt through the source
to find out why.

How come I'm not using libc? Well, I have and do. The app is currently
portable to Windows x64, Linux, Solaris and now working on FreeBSD. The
Solaris, Linux and FreeBSD versions can use libc for OS calls
(different build option via a #define)... But am working on porting the
app so that it's native to the OS (Solaris and Linux already done).
Why? Because I can, and having done so, have found bugs that weren't
apparent under a single OS, or when using libc.

Seriously, porting an app to different OS's (even though most are POSIX
compatible) brings out all the bugs... And who said asm isn't portable?

PS. There are about 5 OS dependent calls that my app makes, and while
I've had no issues porting the others to different OS's the malloc()
code seems to be the most difficult.

--
Darran (aka Chewy509) brought to you by Google Groups!

.

Relevant Pages

  • Re: sbrk vs mmap (FreeBSD)
    ... with FreeBSD. ... This is part of porting an application from Linux ... pointer to the source file would be great - one of the benefits of Open ... The source for the sbrk kernel function is in ...
    (alt.lang.asm)
  • Re: organization
    ... > but the linux way in arranging the source file is really better than ... many people feel that you are attacking FreeBSD.. ... > and a makefile while linux contains about 15 subdirs only. ... Also, as time permits, such as when new drivers are written, old drivers ...
    (freebsd-hackers)
  • Re: organization
    ... freebsd way, it's a fact. ... arch specific file should go in subdir called arch/ ... and a makefile while linux contains about 15 subdirs only. ... >> but the linux way in arranging the source file is really better than ...
    (freebsd-hackers)
  • Re: Porting from linux to FreeBSD (procfs question)
    ... I have a question about porting an application from Linux to FreeBSD. ... The application I want to port, makes an extensive use of the procfs ...
    (freebsd-questions)
  • Porting from linux to FreeBSD (procfs question)
    ... I have a question about porting an application from Linux to FreeBSD. ... The application I want to port, makes an extensive use of the procfs ...
    (freebsd-questions)