goinsane wrote: >> (This assumes the application is 32-bit or at least >> that the system is >> little-endian. Things get more complicated if you >> have to deal with >> 64-bit big-endian systems.) >> > > Hm, that's a point I had not noticed yet. I expected the D scripts running > independent from the system's arch. But as it becomes more complex, it seems > this has to be handled, too.
D scripts run in the context of the kernel. If you've got a 64-bit kernel, then your D scripts run as (effectively) 64-bit applications. User-space applications on a 64-bit system, though, may be either 32-bit or 64-bit; the system supports both simultaneously. That's what adds in a bit of complexity. Things running in the kernel (such as D scripts) need to be aware of what flavor of application is out there when they go mucking around with application data structures -- as with copyin. > Right now, I'm running at 64 bit i86pc . I'm getting a value of the port > (have to verify it), but no value of the ip address. > > self->port = self->sockcont->sin_port; > self->ip_int = (uint_t)self->sockcont->sin_addr.s_addr; Don't forget that the port number will be in network (big-endian) byte order. As for the problem with the IP address, I don't know what could be going on. You might want to try a truss -vall to see if the values you're getting are the ones you're expecting. The alignment of sockaddr_in is such that I'd expect it to work fine over the 32/64 boundary without special handling, so if you're seeing unexpected behavior here, it's time to start dumping everything -- start by printing out the length of the structure that's being copied (perhaps that's wrong) and the first few bytes of the structure to see if it's what you expect. -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
