Well, after tracking down some of the structures being used in the ioctl arguments, and memset() them to zero, I think all of the errors went away without the need to write any additional wrappers other than the pselect() wrapper. Most of those calls were int he bpf-pcap.c file. I am not sure whether that is a worthwhile check-in to make for pcap or not.
-Derek On Wed, Jan 9, 2013 at 10:21 AM, Derek Cole <derek.c...@gmail.com> wrote: > 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
