Thanks, That might be enough information for me to get a start on tackling some of this.
Just for reference, this is the version of valgrind for FreeBSD i've been working off of http://wiki.freebsd.org/Valgrind On Tue, Jan 8, 2013 at 11:32 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Jan 8, 2013, at 7:08 PM, Derek Cole <derek.c...@gmail.com> wrote: > > > Thanks for the detailed response. You are correct that was my stack > overflow post. At the time I posted that I didn't have as clear of an idea > of the problem, so, casting a wide net. > > > >> Valgrind is complaining about several uninitialized variables, *and* > about "unhandled ioctl 0x20004269 with no size/direction hints". > 0x20004269 is _IO('B', 105), which is BIOCPROMISC. BIOCPROMISC takes no > arguments, so there is no size or direction. However, an ioctl that takes > arguments that aren't a simple fixed-size blob would also have no > size/direction hints, so valgrind doesn't just assume there's nothing to > check. If that warning is causing a problem, you'll have to write a > wrapper for that ioctl to let valgrind know that there are no arguments and > therefore that no references to memory are made by it. > > > > I saw that message as well. How did you look up 0x20004269 to know what > that corresponded to? > > Well, I knew that a 4.2BSD-and-later ioctl code is: > > 16 bits of direction and size information; > > 16 bits of ioctl code; > > and that, by convention, UNIX ioctl codes are 8 bits of ASCII character > giving the general class of devices to which the ioctl applies and 8 bits > of code within that class. > > I also knew that, in most of the newer versions of those UN*Xes that have > 4.2BSD-style ioctl codes, the direction and size information is defined in > /usr/include/sys/ioccom.h, so I looked there to find out which of the _IO > macros it was. > > Then I looked up 0x42 in the "man ascii" table; it was 'b', which wasn't > surprising, as that's the class value for BPF devices. I then looked in > /usr/include/sys/bpf.h for ioctl 0x69 = 105. > > > Can you provide some info about writing a wrapper for an ioctl? I am new > to tinkering with this but I was able to get a wrapper for select written > today for my freebsd install. I basically copied the pieces from the > pselect that was already written for linux and put it in the freebsd source > files that came with the port. > > So where do the FreeBSD source files hide? If I look at the FreeBSD ports > collection, there's no "files" subdirectory of > > http://svnweb.freebsd.org/ports/head/devel/valgrind/ > > or > > http://svnweb.freebsd.org/ports/head/devel/valgrind-snapshot/ > > A lot of the wrapper code for Darwin and FreeBSD can probably be similar > or even the same (for BPF ioctls, the code can probably mostly be shared, > modulo handling of stuff such as the Darwin hacks for running {32,64}-bit > userland atop {64,32}-bit kernels - FreeBSD would probably use similar > stuff, but it doesn't have to worry about 64-bit userland atop a 32-bit > kernel the way Darwin does). _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
