Re: 64bit support on netbsd

[Guy Harris <guy () alum mit edu>]

On Feb 9, 2012, at 5:05 AM, David Laight wrote:

> There is a report on one of the netbsd lists (might have
> been a developer-only list) that tcpdump (etc) aren't
> working on 64bit netbsd platforms.
>
> IIRC it had something to do with 'struct timeval' and friends.
>
> I'm not sure of the full details but it might be related to:
> 1) NetBSD recently changing from 32bit to 64bit time_t.
> 2) 'struct timeval' being 48bits for i386 but 64bits for amd64,  
>  and someone trying to run the 32bit pcap code on a 64bit system.

From a quick look at the top-of-trunk bpf.c and bpf.h:

        $ ident bpf.[ch]
        bpf.c:
             $NetBSD: bpf.c,v 1.168 2011/12/16 03:05:23 christos Exp $
             $NetBSD: bpf.c,v 1.168 2011/12/16 03:05:23 christos Exp $

        bpf.h:
             $NetBSD: bpf.h,v 1.58 2011/08/30 14:22:22 bouyer Exp $

it looks as if the BPF driver attempts to provide 32-bit-compatible bufferfuls of packets to 32-bit processes.

*However*, that's not the only place where structures involving times get passed between the kernel and userland.  They 
*also* get passed in the BIOCGRTIMEOUT and BIOCSRTIMEOUT ioctls, the argument to which is a pointer to a struct 
timeval.  This being a BSD-flavored OS, the ioctl cookie includes the size of the structure, so an ioctl with a 32-bit 
struct timeval will have a different ioctl cookie from an ioctl with a 64-bit struct timeval.

> From a quick look at the top of the trunk, _BSD_TIME_T_ is always defined as __int64_t and _BSD_SUSECONDS_T_ is always 
> defined as int, so struct timeval would, *modulo padding at the end* (I presume that's the "48bits for i386 and 64bits 
> for amd64" - presumably meaning "48 bits for 32-bit platforms and 64 bits for 64-bit platforms"), be laid out the 
> same, so that should work as well.

As for pcap files, the time stamp in them is defined to have a 32-bit time-in-seconds value, which will just get padded 
out to 64 bits when reading and chopped to the lower 32 bits when writing on a system with a 64-bit time-in-seconds 
type, so that should work as well.

So there's not much I can do here without more details about the exact problem, including, for example, whether 
somebody's running binaries built on a NetBSD system with a 32-bit time_t on a NetBSD system with a 64-bit time_t.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.