Searched hist:132 (Results 1 - 24 of 24) sorted by relevance
/freebsd-10.0-release/lib/libutil/ | ||
H A D | kinfo_getfile.c | diff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head. This changes struct kinfo_filedesc and kinfo_vmentry such that they are same on both 32 and 64 bit platforms like i386/amd64 and won't require sysctl wrapping. Two new OIDs are assigned. The old ones are available under COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface was never actually released on 7.x. The other main change is to pack the data passed to userland via the sysctl. kf_structsize and kve_structsize are reduced for the copyout. If you have a process with 100,000+ sockets open, the unpacked records require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still seriously unpleasant, but not quite as devastating). A similar problem exists for the vmentry structure - have lots and lots of shared libraries and small mmaps and its copyout gets expensive too. My immediate problem is valgrind. It traditionally achieves this functionality by parsing procfs output, in a packed format. Secondly, when tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled 32 bit binary which ran directly into the differing data structures in 32 vs 64 bit mode. (valgrind uses this to track file descriptor operations and this therefore affected every single 32 bit binary) I've added two utility functions to libutil to unpack the structures into a fixed record length and to make it a little more convenient to use. |
H A D | kinfo_getvmmap.c | diff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head. This changes struct kinfo_filedesc and kinfo_vmentry such that they are same on both 32 and 64 bit platforms like i386/amd64 and won't require sysctl wrapping. Two new OIDs are assigned. The old ones are available under COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface was never actually released on 7.x. The other main change is to pack the data passed to userland via the sysctl. kf_structsize and kve_structsize are reduced for the copyout. If you have a process with 100,000+ sockets open, the unpacked records require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still seriously unpleasant, but not quite as devastating). A similar problem exists for the vmentry structure - have lots and lots of shared libraries and small mmaps and its copyout gets expensive too. My immediate problem is valgrind. It traditionally achieves this functionality by parsing procfs output, in a packed format. Secondly, when tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled 32 bit binary which ran directly into the differing data structures in 32 vs 64 bit mode. (valgrind uses this to track file descriptor operations and this therefore affected every single 32 bit binary) I've added two utility functions to libutil to unpack the structures into a fixed record length and to make it a little more convenient to use. |
H A D | Makefile | diff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head. This changes struct kinfo_filedesc and kinfo_vmentry such that they are same on both 32 and 64 bit platforms like i386/amd64 and won't require sysctl wrapping. Two new OIDs are assigned. The old ones are available under COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface was never actually released on 7.x. The other main change is to pack the data passed to userland via the sysctl. kf_structsize and kve_structsize are reduced for the copyout. If you have a process with 100,000+ sockets open, the unpacked records require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still seriously unpleasant, but not quite as devastating). A similar problem exists for the vmentry structure - have lots and lots of shared libraries and small mmaps and its copyout gets expensive too. My immediate problem is valgrind. It traditionally achieves this functionality by parsing procfs output, in a packed format. Secondly, when tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled 32 bit binary which ran directly into the differing data structures in 32 vs 64 bit mode. (valgrind uses this to track file descriptor operations and this therefore affected every single 32 bit binary) I've added two utility functions to libutil to unpack the structures into a fixed record length and to make it a little more convenient to use. |
H A D | libutil.h | diff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head. This changes struct kinfo_filedesc and kinfo_vmentry such that they are same on both 32 and 64 bit platforms like i386/amd64 and won't require sysctl wrapping. Two new OIDs are assigned. The old ones are available under COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface was never actually released on 7.x. The other main change is to pack the data passed to userland via the sysctl. kf_structsize and kve_structsize are reduced for the copyout. If you have a process with 100,000+ sockets open, the unpacked records require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still seriously unpleasant, but not quite as devastating). A similar problem exists for the vmentry structure - have lots and lots of shared libraries and small mmaps and its copyout gets expensive too. My immediate problem is valgrind. It traditionally achieves this functionality by parsing procfs output, in a packed format. Secondly, when tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled 32 bit binary which ran directly into the differing data structures in 32 vs 64 bit mode. (valgrind uses this to track file descriptor operations and this therefore affected every single 32 bit binary) I've added two utility functions to libutil to unpack the structures into a fixed record length and to make it a little more convenient to use. |
/freebsd-10.0-release/usr.bin/procstat/ | ||
H A D | Makefile | diff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head. This changes struct kinfo_filedesc and kinfo_vmentry such that they are same on both 32 and 64 bit platforms like i386/amd64 and won't require sysctl wrapping. Two new OIDs are assigned. The old ones are available under COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface was never actually released on 7.x. The other main change is to pack the data passed to userland via the sysctl. kf_structsize and kve_structsize are reduced for the copyout. If you have a process with 100,000+ sockets open, the unpacked records require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still seriously unpleasant, but not quite as devastating). A similar problem exists for the vmentry structure - have lots and lots of shared libraries and small mmaps and its copyout gets expensive too. My immediate problem is valgrind. It traditionally achieves this functionality by parsing procfs output, in a packed format. Secondly, when tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled 32 bit binary which ran directly into the differing data structures in 32 vs 64 bit mode. (valgrind uses this to track file descriptor operations and this therefore affected every single 32 bit binary) I've added two utility functions to libutil to unpack the structures into a fixed record length and to make it a little more convenient to use. |
H A D | procstat_vm.c | diff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head. This changes struct kinfo_filedesc and kinfo_vmentry such that they are same on both 32 and 64 bit platforms like i386/amd64 and won't require sysctl wrapping. Two new OIDs are assigned. The old ones are available under COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface was never actually released on 7.x. The other main change is to pack the data passed to userland via the sysctl. kf_structsize and kve_structsize are reduced for the copyout. If you have a process with 100,000+ sockets open, the unpacked records require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still seriously unpleasant, but not quite as devastating). A similar problem exists for the vmentry structure - have lots and lots of shared libraries and small mmaps and its copyout gets expensive too. My immediate problem is valgrind. It traditionally achieves this functionality by parsing procfs output, in a packed format. Secondly, when tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled 32 bit binary which ran directly into the differing data structures in 32 vs 64 bit mode. (valgrind uses this to track file descriptor operations and this therefore affected every single 32 bit binary) I've added two utility functions to libutil to unpack the structures into a fixed record length and to make it a little more convenient to use. |
H A D | procstat_files.c | diff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head. This changes struct kinfo_filedesc and kinfo_vmentry such that they are same on both 32 and 64 bit platforms like i386/amd64 and won't require sysctl wrapping. Two new OIDs are assigned. The old ones are available under COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface was never actually released on 7.x. The other main change is to pack the data passed to userland via the sysctl. kf_structsize and kve_structsize are reduced for the copyout. If you have a process with 100,000+ sockets open, the unpacked records require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still seriously unpleasant, but not quite as devastating). A similar problem exists for the vmentry structure - have lots and lots of shared libraries and small mmaps and its copyout gets expensive too. My immediate problem is valgrind. It traditionally achieves this functionality by parsing procfs output, in a packed format. Secondly, when tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled 32 bit binary which ran directly into the differing data structures in 32 vs 64 bit mode. (valgrind uses this to track file descriptor operations and this therefore affected every single 32 bit binary) I've added two utility functions to libutil to unpack the structures into a fixed record length and to make it a little more convenient to use. |
/freebsd-10.0-release/sys/netgraph/bluetooth/include/ | ||
H A D | ng_btsocket_rfcomm.h | diff 140027 Mon Jan 10 23:39:53 MST 2005 emax Make default RFCOMM session MTU match default L2CAP MTU. This is just a workaround for a know problem with Motorola E1000 phone. Something is wrong with the configuration of L2CAP/RFCOMM channel. Even though we set L2CAP MTU to 132 bytes (default RFCOMM MTU 127 + 5 bytes RFCOMM frame header) and the phone accepts it, the phone still sends oversized L2CAP packets. It appears that the phone wants to use bigger (667 bytes) RFCOMM frames, but it does not segment them according to the configured L2CAP MTU. The 667 bytes RFCOMM frame size corresponds to the default L2CAP MTU of 672 bytes (667 + 5 bytes RFCOMM frame header). This problem only appears if connection was initiated from the phone. I'm not sure who is at fault here, so for now just put workaround in place. Quick look at the spec did not reveal any anwser. Tested by: Jes < jjess at freebsd dot polarhome dot com > MFC after: 3 days |
/freebsd-10.0-release/sys/dev/fb/ | ||
H A D | vesa.c | diff 117710 Thu Jul 17 22:06:10 MDT 2003 robert Make the 80x60, 132x25, 132x43, 132x50, and 132x60 VESA text modes work when using a graphics chipset which identifies itself as `VIA CLE266', used in some VIA EPIA boards. Two values need to be patched in the VESA mode information structure: the widths of the modes mentioned above are encoded in a format which was unknown to the VESA module (and to my copy of the VBE spec.) whereas the window memory segment values seem to be just incorrect. I tested this on a VIA EPIA-M9000 and -M10000. diff 117710 Thu Jul 17 22:06:10 MDT 2003 robert Make the 80x60, 132x25, 132x43, 132x50, and 132x60 VESA text modes work when using a graphics chipset which identifies itself as `VIA CLE266', used in some VIA EPIA boards. Two values need to be patched in the VESA mode information structure: the widths of the modes mentioned above are encoded in a format which was unknown to the VESA module (and to my copy of the VBE spec.) whereas the window memory segment values seem to be just incorrect. I tested this on a VIA EPIA-M9000 and -M10000. diff 117710 Thu Jul 17 22:06:10 MDT 2003 robert Make the 80x60, 132x25, 132x43, 132x50, and 132x60 VESA text modes work when using a graphics chipset which identifies itself as `VIA CLE266', used in some VIA EPIA boards. Two values need to be patched in the VESA mode information structure: the widths of the modes mentioned above are encoded in a format which was unknown to the VESA module (and to my copy of the VBE spec.) whereas the window memory segment values seem to be just incorrect. I tested this on a VIA EPIA-M9000 and -M10000. diff 117710 Thu Jul 17 22:06:10 MDT 2003 robert Make the 80x60, 132x25, 132x43, 132x50, and 132x60 VESA text modes work when using a graphics chipset which identifies itself as `VIA CLE266', used in some VIA EPIA boards. Two values need to be patched in the VESA mode information structure: the widths of the modes mentioned above are encoded in a format which was unknown to the VESA module (and to my copy of the VBE spec.) whereas the window memory segment values seem to be just incorrect. I tested this on a VIA EPIA-M9000 and -M10000. diff 39591 Wed Sep 23 07:59:00 MDT 1998 yokota Fix and update for VESA BIOS support in syscons. - Handle pixel (raster text) mode properly. - Clear screen and paint border right. - Paint text attribute (colors). - Fix off-by-one errors. - Add some sanity checks. - Fix some function prototypes. - Add some comment lines. - Define generic text mode numbers so that the user can just give "80x25", "80x60", "132x25"..., rather than "VGA_xxx", to `vidcontrol' to change the current video mode. `vidoio.c' and `vesa.c' will map these numbers to real video mode numbers appropriate and available with the given video hardware. I believe this will be useful to make syscons more portable across archtectures. |
/freebsd-10.0-release/sys/dev/syscons/ | ||
H A D | scvesactl.c | diff 39591 Wed Sep 23 07:59:00 MDT 1998 yokota Fix and update for VESA BIOS support in syscons. - Handle pixel (raster text) mode properly. - Clear screen and paint border right. - Paint text attribute (colors). - Fix off-by-one errors. - Add some sanity checks. - Fix some function prototypes. - Add some comment lines. - Define generic text mode numbers so that the user can just give "80x25", "80x60", "132x25"..., rather than "VGA_xxx", to `vidcontrol' to change the current video mode. `vidoio.c' and `vesa.c' will map these numbers to real video mode numbers appropriate and available with the given video hardware. I believe this will be useful to make syscons more portable across archtectures. |
H A D | scvidctl.c | diff 39591 Wed Sep 23 07:59:00 MDT 1998 yokota Fix and update for VESA BIOS support in syscons. - Handle pixel (raster text) mode properly. - Clear screen and paint border right. - Paint text attribute (colors). - Fix off-by-one errors. - Add some sanity checks. - Fix some function prototypes. - Add some comment lines. - Define generic text mode numbers so that the user can just give "80x25", "80x60", "132x25"..., rather than "VGA_xxx", to `vidcontrol' to change the current video mode. `vidoio.c' and `vesa.c' will map these numbers to real video mode numbers appropriate and available with the given video hardware. I believe this will be useful to make syscons more portable across archtectures. |
H A D | syscons.h | diff 39591 Wed Sep 23 07:59:00 MDT 1998 yokota Fix and update for VESA BIOS support in syscons. - Handle pixel (raster text) mode properly. - Clear screen and paint border right. - Paint text attribute (colors). - Fix off-by-one errors. - Add some sanity checks. - Fix some function prototypes. - Add some comment lines. - Define generic text mode numbers so that the user can just give "80x25", "80x60", "132x25"..., rather than "VGA_xxx", to `vidcontrol' to change the current video mode. `vidoio.c' and `vesa.c' will map these numbers to real video mode numbers appropriate and available with the given video hardware. I believe this will be useful to make syscons more portable across archtectures. |
H A D | syscons.c | diff 39591 Wed Sep 23 07:59:00 MDT 1998 yokota Fix and update for VESA BIOS support in syscons. - Handle pixel (raster text) mode properly. - Clear screen and paint border right. - Paint text attribute (colors). - Fix off-by-one errors. - Add some sanity checks. - Fix some function prototypes. - Add some comment lines. - Define generic text mode numbers so that the user can just give "80x25", "80x60", "132x25"..., rather than "VGA_xxx", to `vidcontrol' to change the current video mode. `vidoio.c' and `vesa.c' will map these numbers to real video mode numbers appropriate and available with the given video hardware. I believe this will be useful to make syscons more portable across archtectures. |
/freebsd-10.0-release/bin/ls/ | ||
H A D | ls.c | diff 5158 Sun Dec 18 17:00:01 MST 1994 joerg Make ls recognize the COLUMNS environmental variable, even in cases where it does not run on a terminal. This is important e.g. for commands like env COLUMNS=132 ls -CR | lpr -Psome-wide-printer |
/freebsd-10.0-release/sys/dev/sound/pci/ | ||
H A D | emu10k1.c | diff 153799 Wed Dec 28 15:57:36 MST 2005 netchild Fix the order of the stereo channels (left <-> right). From the PR: ---snip--- I think I have found the change which reversed the channels. Revision 1.44 of emu10k1.c, which added Audigy support, has the line emu_wrptr(sc, v->vnum, FXRT, 0xd01c0000); replaced with the following lines: if (sc->audigy) { emu_wrptr(sc, v->vnum, A_FXRT1, v->fxrt1); emu_wrptr(sc, v->vnum, A_FXRT2, v->fxrt2); emu_wrptr(sc, v->vnum, A_SENDAMOUNTS, 0); } else emu_wrptr(sc, v->vnum, FXRT, v->fxrt1 << 16); where v->fxrt1 << 16 == 0xd10c0000 I don't have Audigy, so I'm not sure if the problem affects Audigy cards too. The order of the channels can't be tested by just altering mixer settings. Here's a small program to test if the channels are reversed on your sound card: #include <sys/soundcard.h> #include <fcntl.h> #include <unistd.h> int main(int argc, char **argv) { int fd = open("/dev/dsp", O_WRONLY), format = AFMT_S16_LE; int channels = 2, rate = 22050, i; /* 450 Hz sine wave on left channel, right channel silent */ unsigned char samples[] = {0, 0, 0, 0, 94, 16, 0, 0, 120, 32, 0, 0, 9, 48, 0, 0, 208, 62, 0, 0, 143, 76, 0, 0, 12, 89, 0, 0, 19, 100, 0, 0, 117, 109, 0, 0, 11, 117, 0, 0, 182, 122, 0, 0, 92, 126, 0, 0, 239, 127, 0, 0, 105, 127, 0, 0, 202, 124, 0, 0, 32, 120, 0, 0, 124, 113, 0, 0, 251, 104, 0, 0, 193, 94, 0, 0, 249, 82, 0, 0, 212, 69, 0, 0, 138, 55, 0, 0, 85, 40, 0, 0, 120, 24, 0, 0, 51, 8, 0, 0, 205, 247, 0, 0, 136, 231, 0, 0, 171, 215, 0, 0, 118, 200, 0, 0, 44, 186, 0, 0, 7, 173, 0, 0, 63, 161, 0, 0, 5, 151, 0, 0, 132, 142, 0, 0, 224, 135, 0, 0, 54, 131, 0, 0, 151, 128, 0, 0, 17, 128, 0, 0, 164, 129, 0, 0, 74, 133, 0, 0, 245, 138, 0, 0, 139, 146, 0, 0, 237, 155, 0, 0, 244, 166, 0, 0, 113, 179, 0, 0, 48, 193, 0, 0, 247, 207, 0, 0, 136, 223, 0, 0, 162, 239, 0, 0}; ioctl(fd, SNDCTL_DSP_SETFMT,&format); ioctl(fd, SNDCTL_DSP_CHANNELS,&channels); ioctl(fd, SNDCTL_DSP_SPEED,&rate); for(i=0;i<500;i++) write(fd, &samples, sizeof(samples)); write(fd, &samples, 2); /* swap channels */ for(i=0;i<500;i++) write(fd, &samples, sizeof(samples)); return 0; } You should hear a sound on the left channel followed by a sound on the right channel. If you hear a sound on the right channel first, the channels are reversed. ---snip--- Owners of an audigy card should verify if it DTRT and report back. Noticed by: Matthias Buelow <mkb@mukappabeta.de> Submitted by: Juha-Matti Tilli <juhis@nallukka.net> PR: 72221 |
/freebsd-10.0-release/share/termcap/ | ||
H A D | termcap.src | diff 102279 Thu Aug 22 17:48:13 MDT 2002 schweikh 1) add mvterm 2) add 132 column entries for VESA 3) fix kterm entry tc PR: 1) misc/39628, 2) conf/13918, 3) misc/22660 Submitted by: 1) Daniel Rudy <dcrudy@pacbell.net> Submitted by: 2) Martin Kammerhofer <dada@sbox.tu-graz.ac.at> Submitted by: 3) Koji Mori <mori@tri.asanuma.co.jp> MFC after: 2 weeks |
/freebsd-10.0-release/sys/amd64/amd64/ | ||
H A D | sys_machdep.c | diff 132 Fri Jul 16 18:50:44 MDT 1993 dg Updated kernel files to move occurances of "struct args" syscall argument definitions outside of the function parameter list. This is to reduce the copious warning messages that (non-Jolitz) gcc produces. Also fixed some bogus variable declarations and casts to make the compiler happy. |
H A D | machdep.c | diff 132 Fri Jul 16 18:50:44 MDT 1993 dg Updated kernel files to move occurances of "struct args" syscall argument definitions outside of the function parameter list. This is to reduce the copious warning messages that (non-Jolitz) gcc produces. Also fixed some bogus variable declarations and casts to make the compiler happy. |
/freebsd-10.0-release/sys/dev/puc/ | ||
H A D | pucdata.c | diff 237357 Thu Jun 21 02:58:50 MDT 2012 fjoe Remove Moxa CP-132EL definition (RS422/485-only board). |
/freebsd-10.0-release/sys/i386/i386/ | ||
H A D | sys_machdep.c | diff 132 Fri Jul 16 18:50:44 MDT 1993 dg Updated kernel files to move occurances of "struct args" syscall argument definitions outside of the function parameter list. This is to reduce the copious warning messages that (non-Jolitz) gcc produces. Also fixed some bogus variable declarations and casts to make the compiler happy. |
H A D | machdep.c | diff 132 Fri Jul 16 18:50:44 MDT 1993 dg Updated kernel files to move occurances of "struct args" syscall argument definitions outside of the function parameter list. This is to reduce the copious warning messages that (non-Jolitz) gcc produces. Also fixed some bogus variable declarations and casts to make the compiler happy. |
/freebsd-10.0-release/sys/sys/ | ||
H A D | sysctl.h | diff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head. This changes struct kinfo_filedesc and kinfo_vmentry such that they are same on both 32 and 64 bit platforms like i386/amd64 and won't require sysctl wrapping. Two new OIDs are assigned. The old ones are available under COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface was never actually released on 7.x. The other main change is to pack the data passed to userland via the sysctl. kf_structsize and kve_structsize are reduced for the copyout. If you have a process with 100,000+ sockets open, the unpacked records require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still seriously unpleasant, but not quite as devastating). A similar problem exists for the vmentry structure - have lots and lots of shared libraries and small mmaps and its copyout gets expensive too. My immediate problem is valgrind. It traditionally achieves this functionality by parsing procfs output, in a packed format. Secondly, when tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled 32 bit binary which ran directly into the differing data structures in 32 vs 64 bit mode. (valgrind uses this to track file descriptor operations and this therefore affected every single 32 bit binary) I've added two utility functions to libutil to unpack the structures into a fixed record length and to make it a little more convenient to use. |
/freebsd-10.0-release/sys/net/ | ||
H A D | route.c | diff 133513 Wed Aug 11 15:26:56 MDT 2004 andre Convert the routing table to use an UMA zone for rtentries. The zone is called "rtentry". This saves a considerable amount of kernel memory. R_Zmalloc previously used 256 byte blocks (plus kmalloc overhead) whereas UMA only needs 132 bytes. Idea from: OpenBSD |
/freebsd-10.0-release/sys/kern/ | ||
H A D | kern_proc.c | diff 185548 Tue Dec 02 04:53:59 MST 2008 peter Merge user/peter/kinfo branch as of r185547 into head. This changes struct kinfo_filedesc and kinfo_vmentry such that they are same on both 32 and 64 bit platforms like i386/amd64 and won't require sysctl wrapping. Two new OIDs are assigned. The old ones are available under COMPAT_FREEBSD7 - but it isn't that simple. The superceded interface was never actually released on 7.x. The other main change is to pack the data passed to userland via the sysctl. kf_structsize and kve_structsize are reduced for the copyout. If you have a process with 100,000+ sockets open, the unpacked records require a 132MB+ copyout. With packing, it is "only" ~35MB. (Still seriously unpleasant, but not quite as devastating). A similar problem exists for the vmentry structure - have lots and lots of shared libraries and small mmaps and its copyout gets expensive too. My immediate problem is valgrind. It traditionally achieves this functionality by parsing procfs output, in a packed format. Secondly, when tracing 32 bit binaries on amd64 under valgrind, it uses a cross compiled 32 bit binary which ran directly into the differing data structures in 32 vs 64 bit mode. (valgrind uses this to track file descriptor operations and this therefore affected every single 32 bit binary) I've added two utility functions to libutil to unpack the structures into a fixed record length and to make it a little more convenient to use. |
Completed in 917 milliseconds