Re: [Valgrind-developers] Porting valgrind to FreeBSD

[Doug R. <df...@nl...>]

On Sun, 2004-01-04 at 22:05, Jeremy Fitzhardinge wrote:
> 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...

I'm not sure. I do know that the FreeBSD kernel doesn't try to align
stacks properly before execve even for platforms that need special
alignment. We rely on the C startup code (which we provide along with
libc itself) to apply any extra alignment before calling main.

> 
> > 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?

Probably not. The relavent kernel code (src/sys/vm/vm_unix.c if you want
to read it) just subtracts the new brk value from the 'data section
base' that the ELF loader set and compares it to RLIMIT_DATA. It care
whether or not the pages are mapped.

> 
> > 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)?

Actually, its /libexec/ld-elf.so.1 which gets to place libc.so and
valgrind can control its placement the way it does now - by mapping
other stuff over places it needs to avoid.

> 
> > 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.

Correct.

> 
> > > 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.

There are a fair number of differences in the syscall ABIs but there was
definately a lot of common ground there. I currently get a load of
'defined but not used' warnings for linux syscalls which aren't in the
FreeBSD tables. Maybe separating the syscall pre and post stubs from the
tables and dispatch code would be sufficient?

> 
> 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?

The main difference between linuxthreads and FreeBSD pthreads is that
where in Linux, e.g. a mutex is declared:

	typedef struct pthread_mutex pthread_mutex_t;

in FreeBSD it would be declared:

	typedef struct pthread_mutex *pthread_mutex_t;

The reason for this is to remove sizeof(pthread_mutex) from the pthreads
ABI which makes it easy to substitute different pthreads implementations
without rebuilding client code. Currently I know of at least four
pthreads implementations that use the same ABI.

Coping with this difference was getting very clumsy with several ifdef
sections in almost every function. Also the glibc-specific stuff ended
up changing quite a bit too. In the end it seemed easier to fork the
code.

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

I'm not familiar with sysinfo at all, so probably not.

> 
> 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?

My test system here is approximately a 5.2 prerelease. I would recommend
installing 5.2-RC2.