|
From: Julian S. <js...@ac...> - 2006-08-25 10:13:19
|
---------- Forwarded Message ----------
Subject: Re: FYI: Valgrind 3.2 port to FreeBSD
Date: Tuesday 22 August 2006 08:08
From: Peter Wemm <pe...@we...>
To: Julian Seward <js...@ac...>
Cc: Nicholas Nethercote <nj...@cs...>
> On Tuesday 15 August 2006 22:59, Peter Wemm wrote:
> > Progress update:
>
> Cool!
>
> > up in the last email yet. But I thought a FYI might be in order.
>
> Indeed; good to see progress.
>
> > My most recent "problem" was aspacemgr.c:get_name_from_fd() and
> > resolve_filename() in m_libcfile.c. We have no /proc/self/fd/<nn>
> > or equivalent. I didn't want to deal with adding code to track
> > names associated with fd's so I cheated and used a kernel module to
> > extract the current pathnames. It is a hack of the worst kind, but
> > I don't want to deal with it right now. I think we might add the
> > functionality to FreeBSD and use the kernel modules for older
> > releases.
>
> Do you need to know these names? What happens if you just produce
> fake strings with no useful info? I'm moderately sure m_aspacemgr
> doesn't really care what files are called - that's just for being
> pretty for the user's benefit.
The main consumer appears to be the debuginfo code for doing stack
traces. The /proc/curproc/map file on FreeBSD 4.x does not have a
filename (5.x+ does, like linux). With neither of Linux's methods
available, stack traces are reported in plain hex. When at least one
method is added we get function name and filename mappings with the
stack traces. I'm a little puzzled though, because there seem to be
places where filenames are tracked internally within Valgrind. Perhaps
only with --track-fds enabled or something? I haven't gone looking too
far yet - there is plenty more low hanging fruit to deal with yet.
> > BTW: the above traces appear to be real. valgrind 2.2 also
> > complains about the same problem, in spite of the protests from the
> > author of the code in question that it isn't possible...
>
> There are various classes of false errors that tend to happen,
> especially in libcs, and especially when bringing the system up on
> new platforms. Let me know if you want help chasing this down.
FreeBSD's libc doesn't have the __libc_freeres() infrastructure either.
That makes for a noisy report if you let Valgrind show you the
allocated-but-referenced memory left over by libc. Rather noisy in
fact. :)
My main plan is to get the core infrastructure working. I've got many
offers of help within the FreeBSD group to share the workload of grunt
work like verifying the syscall wrappers etc so I've been more focusing
on getting something running so that I can distribute my work a bit.
Signals are the last big phase-1 item - I'm fighting with them now.
They are winning so far..
Oh.. this might amuse you. FreeBSD's siginfo definitions lie. si_code
is #defined similarly as on Linux, but the actual codes that the kernel
generates are directly mapped from the initial trap numbers and have
absolutely no bearing on what is in the system include files (!!).
eg: the headers say:
/* codes for SIGSEGV */
#define SEGV_MAPERR 1 /* Address not mapped to object. */
#define SEGV_ACCERR 2 /* Invalid permissions for mapped */
/* object. */
BUT.. the kernel uses T_PAGEFLT (12) to indicate a page fault and
neither of the two listed values.
Sigh. I'm lost for words.
What's worse is that I know that some applications use this..
> J
--
Peter Wemm - pe...@we...; peter@FreeBSD.org; pe...@ya...
"All of this is for nothing if we don't go to the stars" - JMS/B5
-------------------------------------------------------
|