Re: [Valgrind-developers] Porting valgrind to FreeBSD

[Jeremy F. <je...@go...>]

On Sun, 2004-01-04 at 02:42, Doug Rabson wrote:
> Thats right. My FreeBSD system started valgrind with a stack that wasn't
> aligned to 16 bytes and this confused fix_auxv enough to corrupt the
> auxv entries given to stage2.

Hm, I wonder if that code is ever needed...

> The main problem (I think) is that the default data size limit for
> FreeBSD is only 0.5G. We do overcommit by default but moving the brk
> this way generates valid mappings (lazy allocated zero-filled mappings
> but still valid) for the entire ~3G address space and this is greater
> than the limit.

Yep.  Then they all get unmapped again immediately afterwards.  Would it
help to make a loop which increases brk by a bit, unmaps the pages, etc
until brk is at the right place?

> Overriding brk, sbrk (and even malloc itself) is perfectly safe in
> FreeBSD and it should override all ways that the syscall can be called
> apart from a pathological use of syscall(3). I made sure that stage2 was
> able to call malloc safely with these changes although there was a
> problem with non-trivial use of malloc because stage2's copy of libc.so
> ended up being loaded very close to the end of stage2 which didn't leave
> much spare to expand the 'brk'.

Hm, yes, the kernel gets to place it, so I guess it could do that.  Can
we convince it to place it below stage2 (which is what happens on
Linux)?

> I think that RLIMIT_DATA in FreeBSD governs the virtual size of the
> brk-managed region. The libc implementation will not fall back to mmap
> if sbrk (or brk) fails.

OK.  And I presume brk/sbrk are not allowed to grow the brk segment
beyond the next mapping up.

> > I think the best thing to do is use this as a basis for factoring all
> > the OS-specific code into OS-specific files.
> 
> Right - I think that process has already been started.

Hm.  After looking at the patch in a bit more detail, the changes are
smaller than I would have guessed.  I'm pleased to see that almost all
of vg_syscalls.c is common.  I definitely don't want to duplicate common
stuff, nor do I want to have lots of ifdefs, so the division will need
to be more fine-grained than I first thought.

I didn't really look at the differences between vg_libpthread.c and
vg_libpthread_freebsd.c, but they seemed pretty similar.  Why the split?


Other things: does FreeBSD have the same sysinfo page mechanism as Linux
now? 

And which version of FreeBSD should I download and install to try your
stuff out?  Would it be the New Technology release 5.1?  5.2?

	J