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
