Re: qemu-x86_64-static has target_freebsd_flock being too small (__packed use issue) [subject correction: fixed to be "too small"]
[Just correcting the "larger" to be "smaller".]
On 2019-Jan-4, at 19:29, Mark Millard wrote:
[qemu-aarch64-static has the same problem but qemu-armv7-sstatic does not. The
context here
is FreeBSD head -r341836 based and ports head -r488859 based.]
Note: I assume that "struct target_freebsd_flock" is meant to match the memory
layout
of the target's native "struct flock". Otherwise the reported differences
below could be irrelevant.
For amd64 and aarch64 the following code:
printf("sizeof(struct flock) = %lu\n", (unsigned long) sizeof(struct
flock));
printf("l_start %lu\n", (unsigned long) offsetof(struct flock, l_start));
printf("l_len %lu\n", (unsigned long) offsetof(struct flock, l_len));
printf("l_pid %lu\n", (unsigned long) offsetof(struct flock, l_pid));
printf("l_type %lu\n", (unsigned long) offsetof(struct flock, l_type));
printf("l_whence %lu\n", (unsigned long) offsetof(struct flock,
l_whence));
printf("l_sysid %lu\n", (unsigned long) offsetof(struct flock, l_sysid));
produces:
sizeof(struct flock) = 32
l_start 0
l_len 8
l_pid 16
l_type 20
l_whence 22
l_sysid 24
However gdb reports for qemu-x86_64-static and qemu-aarch64-static
and qemu-arm-static:
(gdb) p/d sizeof(struct target_freebsd_flock)
$10 = 28
(gdb) p/d &((struct target_freebsd_flock *)0)->l_start
$11 = 0
(gdb) p/d &((struct target_freebsd_flock *)0)->l_len
$12 = 8
(gdb) p/d &((struct target_freebsd_flock *)0)->l_pid
$13 = 16
(gdb) p/d &((struct target_freebsd_flock *)0)->l_type
$14 = 20
(gdb) p/d &((struct target_freebsd_flock *)0)->l_whence
$15 = 22
(gdb) p/d &((struct target_freebsd_flock *)0)->l_sysid
$16 = 24
So only the overall size is different for this information. But:
struct target_freebsd_flock {
int64_t l_start;
int64_t l_len;
int32_t l_pid;
int16_t l_type;
int16_t l_whence;
int32_t l_sysid;
} QEMU_PACKED;
with a potential packed vs. /usr/include/sys/fcntl.h :
struct flock {
off_t l_start;/* starting offset */
off_t l_len; /* len = 0 means until end of file */
pid_t l_pid; /* lock owner */
short l_type; /* lock type: read/write, etc. */
short l_whence; /* type of l_start */
int l_sysid;/* remote system id or zero for local */
};
with no potential __packed.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
qemu-x86_64-static has target_freebsd_flock being too large (__packed use issue)
[qemu-aarch64-static has the same problem but qemu-armv7-sstatic does not. The
context here
is FreeBSD head -r341836 based and ports head -r488859 based.]
Note: I assume that "struct target_freebsd_flock" is meant to match the memory
layout
of the target's native "struct flock". Otherwise the reported differences
below could be irrelevant.
For amd64 and aarch64 the following code:
printf("sizeof(struct flock) = %lu\n", (unsigned long) sizeof(struct
flock));
printf("l_start %lu\n", (unsigned long) offsetof(struct flock,
l_start));
printf("l_len %lu\n", (unsigned long) offsetof(struct flock, l_len));
printf("l_pid %lu\n", (unsigned long) offsetof(struct flock, l_pid));
printf("l_type %lu\n", (unsigned long) offsetof(struct flock, l_type));
printf("l_whence %lu\n", (unsigned long) offsetof(struct flock,
l_whence));
printf("l_sysid %lu\n", (unsigned long) offsetof(struct flock,
l_sysid));
produces:
sizeof(struct flock) = 32
l_start 0
l_len 8
l_pid 16
l_type 20
l_whence 22
l_sysid 24
However gdb reports for qemu-x86_64-static and qemu-aarch64-static
and qemu-arm-static:
(gdb) p/d sizeof(struct target_freebsd_flock)
$10 = 28
(gdb) p/d &((struct target_freebsd_flock *)0)->l_start
$11 = 0
(gdb) p/d &((struct target_freebsd_flock *)0)->l_len
$12 = 8
(gdb) p/d &((struct target_freebsd_flock *)0)->l_pid
$13 = 16
(gdb) p/d &((struct target_freebsd_flock *)0)->l_type
$14 = 20
(gdb) p/d &((struct target_freebsd_flock *)0)->l_whence
$15 = 22
(gdb) p/d &((struct target_freebsd_flock *)0)->l_sysid
$16 = 24
So only the overall size is different for this information. But:
struct target_freebsd_flock {
int64_t l_start;
int64_t l_len;
int32_t l_pid;
int16_t l_type;
int16_t l_whence;
int32_t l_sysid;
} QEMU_PACKED;
with a potential packed vs. /usr/include/sys/fcntl.h :
struct flock {
off_t l_start;/* starting offset */
off_t l_len; /* len = 0 means until end of file */
pid_t l_pid; /* lock owner */
short l_type; /* lock type: read/write, etc. */
short l_whence; /* type of l_start */
int l_sysid;/* remote system id or zero for local */
};
with no potential __packed.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
qemu-x86_64-static has target_msghdr's msg_controllen field with the wrong size so its msg_flags is at the wrong offset and target_msghdr is too large
[qemu-aarch64-static has the same problem but qemu-armv7-sstatic does not. The
context here
is FreeBSD head -r341836 based and ports head -r488859 based.]
Note: I assume that "struct target_msghdr" is meant to match the memory layout
of the target's native "struct msghdr". Otherwise the reported differences
below could be irrelevant.
For amd64 and aarch64 the following code:
printf("sizeof(struct msghdr) = %lu\n", (unsigned long) sizeof(struct
msghdr));
printf("msg_name %lu\n", (unsigned long) offsetof(struct msghdr,
msg_name));
printf("msg_namelen %lu\n", (unsigned long) offsetof(struct msghdr,
msg_namelen));
printf("msg_iov %lu\n", (unsigned long) offsetof(struct msghdr,
msg_iov));
printf("msg_iovlen %lu\n", (unsigned long) offsetof(struct msghdr,
msg_iovlen));
printf("msg_control %lu\n", (unsigned long) offsetof(struct msghdr,
msg_control));
printf("msg_controllen %lu\n", (unsigned long) offsetof(struct msghdr,
msg_controllen));
printf("msg_flags %lu\n", (unsigned long) offsetof(struct msghdr,
msg_flags));
produces:
sizeof(struct msghdr) = 48
msg_name 0
msg_namelen 8
msg_iov 16
msg_iovlen 24
msg_control 32
msg_controllen 40
msg_flags 44
Note: msg_controllen was apparently 4 bytes wide on these 64-bit architectures.
However gdb reports for qemu-x86_64-static and qemu-aarch64-static:
(gdb) p/d sizeof(struct target_msghdr)
$1 = 56
(gdb) p/d &((struct target_msghdr *)0)->msg_name
$2 = 0
(gdb) p/d &((struct target_msghdr *)0)->msg_namelen
$3 = 8
(gdb) p/d &((struct target_msghdr *)0)->msg_iov
$4 = 16
(gdb) p/d &((struct target_msghdr *)0)->msg_iovlen
$5 = 24
(gdb) p/d &((struct target_msghdr *)0)->msg_control
$6 = 32
(gdb) p/d &((struct target_msghdr *)0)->msg_controllen
$7 = 40
(gdb) p/d &((struct target_msghdr *)0)->msg_flags
$8 = 48
Note the larger size (56 instead of 48) and that msg_controllen 's size
puts msg_flags at the wrong offset.
Notably for armv7, gdb's information for armv7 agrees with:
sizeof(struct msghdr) = 28
msg_name 0
msg_namelen 4
msg_iov 8
msg_iovlen 12
msg_control 16
msg_controllen 20
msg_flags 24
Apparently msg_controllen should always be 4 bytes wide, even on
64-bit architectures instead of tracking the 64-bit vs. 32-bit
status for the architecture.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: How much memory to compile www/chromium?
> > On 2019-Jan-1, at 10:21, bob prohaska wrote: > > > On Tue, Dec 18, 2018 at 09:49:03AM -0800, bob prohaska wrote: > >> > >> Setting MAKE_JOBS_NUMBER_LIMIT=2 allowed www/chromium to compile > >> successfully over > >> several days. The -DBATCH option was used, in hopes it'd fetch the right > >> options. > >> > > > > Just for fun I added a mechanical hard disk with a 4 GB swap partition and > > re-ran > > the www/chromium compilation with MAKE_JOBS_NUMBER_LIMIT unset, to see what > > happens. > > OOMA was turned off with vm.pageout_oom_seq="2048" in /boot/loader.conf. > > > > After ~11 days the process finished. Log files of gstat output and make > > output are at > > http://www.zefox.net/~fbsd/rpi3/swaptests/r342204/chromium/mech_sd/ > > > > As a further test, I'ved added two additional USB flash swap devices and am > > re-running > > the compilation of www/chromium. The swap layout is quite lopsided, with > > the USB flash > > devices having only 2 GB swap partitions on each, contrasting to the 4 GB > > swap partitions > > on the microSD card and mechanical disk. > > The attempt to compile chromium using four USB swap partitions didn't complete, but it might have gotten far enough to be surprising. Swap use peaked around 2.4 GB, while the dual swap partition setup used around 3.5 GB of swap at maximum. The make failure happened near the 17000 counter point, when the controlling ssh connection was dropped. I _think_ that's past the point of maximum swap use, but I'll have to re-try to make sure. The log files are at http://www.zefox.net/~fbsd/rpi3/swaptests/r342204/chromium/flash_mech_sd/ in case anybody is curious. Thanks for reading, bob prohaska ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ lang/adacontrol | 1.18r9 | 1.20r7 +-+ science/psychopy| 1.90.3 | 3.0.0 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: lang/ocaml
Hi! > Current version of ocaml is 4.02.3, but newest is 4.07. > Could ocaml port be updated to newest version please? The attempt to do so can be followed at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218333 -- p...@freebsd.org +49 171 3101372 One year to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD Port: lang/ocaml
Hello, Current version of ocaml is 4.02.3, but newest is 4.07. Could ocaml port be updated to newest version please? -- /* * Serpent7776 */ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
