qemu-arm-static has target_shmd_ds too small vs. arm native's shmid_ds
[The context here is FreeBSD head -r341836 based and ports head -r488859 based.]
Note: I assume that "struct target_shmd_ds" is meant to match the memory layout
of the target's native "struct shmid_ds". Otherwise the reported differences
below could be irrelevant.
For armv7 (and likely armv6) the following code:
printf("sizeof(struct shmid_ds) = %lu\n", (unsigned long) sizeof(struct
shmid_ds));
printf("shm_perm %lu\n", (unsigned long) offsetof(struct shmid_ds,
shm_perm));
printf("shm_segsz %lu\n", (unsigned long) offsetof(struct shmid_ds,
shm_segsz));
printf("shm_lpid %lu\n", (unsigned long) offsetof(struct shmid_ds,
shm_lpid));
printf("shm_cpid %lu\n", (unsigned long) offsetof(struct shmid_ds,
shm_cpid));
printf("shm_nattch %lu\n", (unsigned long) offsetof(struct shmid_ds,
shm_nattch));
printf("shm_atime %lu\n", (unsigned long) offsetof(struct shmid_ds,
shm_atime));
printf("shm_dtime %lu\n", (unsigned long) offsetof(struct shmid_ds,
shm_dtime));
printf("shm_ctime %lu\n", (unsigned long) offsetof(struct shmid_ds,
shm_ctime));
produces:
sizeof(struct shmid_ds) = 64
shm_perm 0
shm_segsz 24
shm_lpid 28
shm_cpid 32
shm_nattch 36
shm_atime 40
shm_dtime 48
shm_ctime 56
However gdb reports for qemu-arm-static (on amd64):
(gdb) p/d &((struct target_shmid_ds *)0)->shm_perm
$33 = 0
(gdb) p/d &((struct target_shmid_ds *)0)->shm_segsz
$34 = 24
(gdb) p/d &((struct target_shmid_ds *)0)->shm_lpid
$35 = 28
(gdb) p/d &((struct target_shmid_ds *)0)->shm_cpid
$36 = 32
(gdb) p/d &((struct target_shmid_ds *)0)->shm_nattch
$37 = 36
(gdb) p/d &((struct target_shmid_ds *)0)->shm_atime
$38 = 40
(gdb) p/d &((struct target_shmid_ds *)0)->shm_dtime
$39 = 44
(gdb) p/d &((struct target_shmid_ds *)0)->shm_ctime
$40 = 48
so after shm_atime the offsets are different.
/usr/include/sys/shm.h has:
struct shmid_ds {
struct ipc_perm shm_perm; /* operation permission structure */
size_t shm_segsz; /* size of segment in bytes */
pid_t shm_lpid; /* process ID of last shared memory op */
pid_t shm_cpid; /* process ID of creator */
shmatt_tshm_nattch; /* number of current attaches */
time_t shm_atime; /* time of last shmat() */
time_t shm_dtime; /* time of last shmdt() */
time_t shm_ctime; /* time of last change by shmctl() */
};
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall_defs.h
has:
struct target_shmid_ds {
struct target_ipc_perm shm_perm; /* peration permission structure */
abi_ulong shm_segsz; /* size of segment in bytes */
int32_t shm_lpid; /* process ID of last shared memory op */
int32_t shm_cpid; /* process ID of creator */
int32_t shm_nattch; /* number of current attaches */
abi_ulong shm_atime; /* time of last shmat() */
abi_ulong shm_dtime; /* time of last shmdt() */
abi_ulong shm_ctime; /* time of last change by shmctl() */
};
abi_ulong's for shm_atime, shm_dtime, and shm_ctime are the wrong
size for armv7: arm uses 64-bit time_t. As of 12+ only i386
uses 32-bit time_t if I understand right. In 11.x 32-bit powerpc
also uses 32-bit time_t.
===
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-arm-static has target_semd_ds too small vs. arm natives semid_ds
[The context here is FreeBSD head -r341836 based and ports head -r488859 based.]
Note: I assume that "struct target_semd_ds" is meant to match the memory layout
of the target's native "struct semid_ds". Otherwise the reported differences
below could be irrelevant.
For armv7 (and likely armv6) the following code:
printf("sizeof(struct semid_ds) = %lu\n", (unsigned long) sizeof(struct
semid_ds));
printf("sem_perm %lu\n", (unsigned long) offsetof(struct semid_ds,
sem_perm));
printf("__sem_base %lu\n", (unsigned long) offsetof(struct semid_ds,
__sem_base));
printf("sem_nsems %lu\n", (unsigned long) offsetof(struct semid_ds,
sem_nsems));
printf("sem_otime %lu\n", (unsigned long) offsetof(struct semid_ds,
sem_otime));
printf("sem_ctime %lu\n", (unsigned long) offsetof(struct semid_ds,
sem_ctime));
produces:
sizeof(struct semid_ds) = 48
sem_perm 0
__sem_base 24
sem_nsems 28
sem_otime 32
sem_ctime 40
However gdb reports for qemu-arm-static (on amd64):
(gdb) p/d sizeof(struct target_semid_ds)
$25 = 40
(gdb) p/d &((struct target_semid_ds *)0)->sem_perm
$26 = 0
(gdb) p/d &((struct target_semid_ds *)0)->sem_base
$27 = 24
(gdb) p/d &((struct target_semid_ds *)0)->sem_nsems
$28 = 28
(gdb) p/d &((struct target_semid_ds *)0)->sem_otime
$29 = 32
(gdb) p/d &((struct target_semid_ds *)0)->sem_ctime
$30 = 36
so after sem_otime the offsets are different.
/usr/include/sys/sem.h has:
struct semid_ds {
struct ipc_perm sem_perm; /* operation permission struct */
struct sem *__sem_base;/* pointer to first semaphore in set */
unsigned short sem_nsems; /* number of sems in set */
time_t sem_otime; /* last operation time */
time_t sem_ctime; /* last change time */
/* Times measured in secs since */
/* 00:00:00 UTC, Jan. 1, 1970, without
leap seconds */
};
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall_defs.h
has:
struct target_semid_ds {
struct target_ipc_perm sem_perm; /* operation permission struct */
abi_ulong sem_base; /* pointer to first semaphore in set */
uint16_tsem_nsems; /* number of sems in set */
abi_ulong sem_otime; /* last operation time */
abi_ulong sem_ctime; /* times measured in secs */
};
abi_ulong's for sem_otime, and sem_otime are the wrong
size for armv7: arm uses 64-bit time_t. As of 12+ only i386
uses 32-bit time_t if I understand right. In 11.x 32-bit powerpc
also uses 32-bit time_t.
===
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-arm-static has target_msqid_ds too small vs. arm natives msqid_ds
[The context here is FreeBSD head -r341836 based and ports head -r488859 based.]
Note: I assume that "struct target_msqid_ds" is meant to match the memory layout
of the target's native "struct msqid_ds". Otherwise the reported differences
below could be irrelevant.
For armv7 (and likely armv6) the following code:
printf("sizeof(struct msqid_ds) = %lu\n", (unsigned long) sizeof(struct
msqid_ds));
printf("msg_perm %lu\n", (unsigned long) offsetof(struct msqid_ds,
msg_perm));
printf("__msg_first %lu\n", (unsigned long) offsetof(struct msqid_ds,
__msg_first));
printf("__msg_last %lu\n", (unsigned long) offsetof(struct msqid_ds,
__msg_last));
printf("msg_cbytes %lu\n", (unsigned long) offsetof(struct msqid_ds,
msg_cbytes));
printf("msg_qnum %lu\n", (unsigned long) offsetof(struct msqid_ds,
msg_qnum));
printf("msg_qbytes %lu\n", (unsigned long) offsetof(struct msqid_ds,
msg_qbytes));
printf("msg_lspid %lu\n", (unsigned long) offsetof(struct msqid_ds,
msg_lspid));
printf("msg_lrpid %lu\n", (unsigned long) offsetof(struct msqid_ds,
msg_lrpid));
printf("msg_stime %lu\n", (unsigned long) offsetof(struct msqid_ds,
msg_stime));
printf("msg_rtime %lu\n", (unsigned long) offsetof(struct msqid_ds,
msg_rtime));
printf("msg_ctime %lu\n", (unsigned long) offsetof(struct msqid_ds,
msg_ctime));
produces:
sizeof(struct msqid_ds) = 80
msg_perm 0
__msg_first 24
__msg_last 28
msg_cbytes 32
msg_qnum 36
msg_qbytes 40
msg_lspid 44
msg_lrpid 48
msg_stime 56
msg_rtime 64
msg_ctime 72
However gdb reports for qemu-arm-static (on amd64):
(gdb) p/d sizeof(struct target_msqid_ds)
$14 = 64
(gdb) p/d &((struct target_msqid_ds *)0)->msg_first
$15 = 24
(gdb) p/d &((struct target_msqid_ds *)0)->msg_last
$16 = 28
(gdb) p/d &((struct target_msqid_ds *)0)->msg_cbytes
$17 = 32
(gdb) p/d &((struct target_msqid_ds *)0)->msg_qnum
$18 = 36
(gdb) p/d &((struct target_msqid_ds *)0)->msg_qbytes
$19 = 40
(gdb) p/d &((struct target_msqid_ds *)0)->msg_lspid
$20 = 44
(gdb) p/d &((struct target_msqid_ds *)0)->msg_lrpid
$21 = 48
(gdb) p/d &((struct target_msqid_ds *)0)->msg_stime
$22 = 52
(gdb) p/d &((struct target_msqid_ds *)0)->msg_rtime
$23 = 56
(gdb) p/d &((struct target_msqid_ds *)0)->msg_ctime
$24 = 60
so after msg_lrpid the offsets are different.
/usr/include/sys/msg.h has:
struct msqid_ds {
struct ipc_perm msg_perm; /* msg queue permission bits */
struct msg *__msg_first; /* first message in the queue */
struct msg *__msg_last;/* last message in the queue */
msglen_t msg_cbytes;/* number of bytes in use on the queue */
msgqnum_t msg_qnum; /* number of msgs in the queue */
msglen_t msg_qbytes;/* max # of bytes on the queue */
pid_t msg_lspid; /* pid of last msgsnd() */
pid_t msg_lrpid; /* pid of last msgrcv() */
time_t msg_stime; /* time of last msgsnd() */
time_t msg_rtime; /* time of last msgrcv() */
time_t msg_ctime; /* time of last msgctl() */
};
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall_defs.h
has:
struct target_msqid_ds {
struct target_ipc_perm msg_perm; /* msg queue permission bits */
abi_ulong msg_first; /* first message in the queue */
abi_ulong msg_last; /* last message in the queue */
abi_ulong msg_cbytes; /* # of bytes in use on the queue */
abi_ulong msg_qnum; /* number of msgs in the queue */
abi_ulong msg_qbytes; /* max # of bytes on the queue */
int32_t msg_lspid; /* pid of last msgsnd() */
int32_t msg_lrpid; /* pid of last msgrcv() */
abi_ulong msg_stime; /* time of last msgsnd() */
abi_ulong msg_rtime; /* time of last msgrcv() */
abi_ulong msg_ctime; /* time of last msgctl() */
};
abi_ulong's for msg_stime, msg_rtime, and msg_ctime are the wrong
size for armv7: arm uses 64-bit time_t. As of 12+ only i386
uses 32-bit time_t if I understand right. In 11.x 32-bit powerpc
also uses 32-bit time_t.
===
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-*-static struct target_msgbuf is greatly mismatched with /usr/include/sys/msgbuf.h 's struct msgbuf
[The context here is FreeBSD head -r341836 based and ports head -r488859 based.]
/usr/include/sys/msgbuf.h has:
struct msgbuf {
char *msg_ptr;/* pointer to buffer */
#define MSG_MAGIC 0x063062
u_int msg_magic;
u_int msg_size;/* size of buffer area */
u_int msg_wseq;/* write sequence number */
u_int msg_rseq;/* read sequence number */
u_int msg_cksum; /* checksum of contents */
u_int msg_seqmod; /* range for sequence numbers */
intmsg_lastpri; /* saved priority value */
u_int msg_flags;
#define MSGBUF_NEEDNL 0x01/* set when newline needed */
struct mtx msg_lock;/* mutex to protect the buffer */
};
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/syscall_defs.h
has:
struct target_msgbuf {
abi_longmtype; /* message type */
charmtext[1]; /* body of message */
};
I'm guessing here that target_msgbuf is not meant to be a match to
msgbuf . Either way, there is no point in comparing sizes or field
offsets as things are now.
===
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-arm-static has target_prpsinfo missing pr_pid field so target_prpsinfo is too small
[The context here is FreeBSD head -r341836 based and ports head -r488859 based.]
Note: I assume that "struct target_prpsinfo" is meant to match the memory layout
of the target's native "struct prpsinfo". Otherwise the reported differences
below could be irrelevant.
Note: struct target_prpsinfo is in (for my context):
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/elfload.c
For armv7 (and likely armv6) the following code:
printf("sizeof(struct prpsinfo) = %lu\n", (unsigned long) sizeof(struct
prpsinfo));
printf("pr_version %lu\n", (unsigned long) offsetof(struct prpsinfo,
pr_version));
printf("pr_psinfosz %lu\n", (unsigned long) offsetof(struct prpsinfo,
pr_psinfosz));
printf("pr_fname %lu\n", (unsigned long) offsetof(struct prpsinfo,
pr_fname));
printf("pr_psargs %lu\n", (unsigned long) offsetof(struct prpsinfo,
pr_psargs));
printf("pr_pid %lu\n", (unsigned long) offsetof(struct prpsinfo,
pr_pid));
produces:
sizeof(struct prpsinfo) = 112
pr_version 0
pr_psinfosz 4
pr_fname 8
pr_psargs 25
pr_pid 108
However gdb reports for qemu-arm-static (on amd64):
(gdb) p/d sizeof(struct target_prpsinfo)
$7 = 108
(gdb) p/d &((struct target_prpsinfo *)0)->pr_version
$8 = 0
(gdb) p/d &((struct target_prpsinfo *)0)->pr_psinfosz
$9 = 4
(gdb) p/d &((struct target_prpsinfo *)0)->pr_fname
$10 = 8
(gdb) p/d &((struct target_prpsinfo *)0)->pr_psargs
$11 = 25
(gdb) p/d &((struct target_prpsinfo *)0)->pr_pid
There is no member named pr_pid.
So the fields prior to pr_pid have matching offsets and there
is no extra padding added before pr_pid for native armv7.
/usr/include/sys/procinfo.h has:
typedef struct prpsinfo {
int pr_version; /* Version number of struct (1) */
size_t pr_psinfosz;/* sizeof(prpsinfo_t) (1) */
charpr_fname[PRFNAMESZ+1]; /* Command name, null terminated (1) */
charpr_psargs[PRARGSZ+1]; /* Arguments, null terminated (1) */
pid_t pr_pid; /* Process ID (1a) */
} prpsinfo_t;
pr_pid was added in -r308009 (2016-oct-28) and is in 11.2 .
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/elfload.c
has:
typedef struct target_prpsinfo {
int32_t pr_version; /* Version number of struct (1) */
abi_ulong pr_psinfosz;/* sizeof(prpsinfo_t) (1) */
charpr_fname[TARGET_PRFNAMESZ+1]; /* Command name + NULL (1) */
charpr_psargs[TARGET_PRARGSZ+1]; /* Arguments + NULL (1) */
} target_prpsinfo_t;
===
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-arm-static has target_sigframe missing sf_fvp field so target_sigframe is too small
[The context here is FreeBSD head -r341836 based and ports head -r488859 based.]
Note: I assume that "struct target_sigframe" is meant to match the memory layout
of the target's native "struct sigframe". Otherwise the reported differences
below could be irrelevant.
For armv7 (and likely armv6) the following code:
printf("sizeof(struct sigframe) = %lu\n", (unsigned long) sizeof(struct
sigframe));
// arm:
printf("sf_si %lu\n", (unsigned long) offsetof(struct sigframe, sf_si));
printf("sf_uc %lu\n", (unsigned long) offsetof(struct sigframe, sf_uc));
printf("sf_vfp %lu\n", (unsigned long) offsetof(struct sigframe,
sf_vfp));
produces:
sizeof(struct sigframe) = 592
sf_si 0
sf_uc 64
sf_vfp 328
However gdb reports for qemu-arm-static (on amd64):
(gdb) p/d sizeof(struct target_sigframe)
$3 = 324
(gdb) p/d &((struct target_sigframe *)0)->sf_si
$4 = 0
(gdb) p/d &((struct target_sigframe *)0)->sf_uc
$5 = 64
(gdb) p/d &((struct target_sigframe *)0)->sf_vfp
There is no member named sf_vfp.
So the first two fields have matching offsets.
But note: sf_vfp is at 328, after the size of target_sigframe (324).
It looks like both contexts have 260 for the size of sf_uc so the
difference is padding before sf_vfp .
/usr/include/machine/frame.h has:
struct sigframe {
siginfo_t sf_si; /* actual saved siginfo */
ucontext_t sf_uc; /* actual saved ucontext */
mcontext_vfp_t sf_vfp; /* actual saved VFP context */
};
sf_vfp was added in -r315947 (2017-Mar-26) and is in 11.2 .
/wrkdirs/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-4ef7d07/bsd-user/arm/target_arch_signal.h
has:
struct target_sigframe {
target_siginfo_tsf_si; /* saved siginfo */
target_ucontext_t sf_uc; /* saved ucontext */
};
===
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: vim - GTK2 or GTK3?
On Thu, Jan 3, 2019 at 11:43 AM Niclas Zeising wrote: > > On 1/3/19 6:08 PM, Miroslav Lachman wrote: > > Adriaan de Groot wrote on 2019/01/03 14:28: > >> Niclas wrote: > >> > >> On Thursday, 3 January 2019 13:00:02 CET > >> freebsd-ports-requ...@freebsd.org > >> wrote: > Firefox and Chromium both depend on GTK3, so it's highly likely that a > typical desktop user has GTK3 installed. > >>> > >>> +1, GTK3 is probably the best choice. > >>> > >>> As a side note, it looks like libreoffice defaults to GTK2 as well, > >>> perhaps it should be switched to GTK3 also? > >> > >> As a not-really-GTK-using person, I still have both GTK2 and GTK3 > >> installed on > >> my system running KDE Plasma. Not for vim though: > >> > >> Installed packages to be REMOVED: > >> gtk2-2.24.32 > >> fontforge-20170731 > >> mftrace-1.2.18_1 > >> > >> Installed packages to be REMOVED: > >> gtk3-3.22.30_4 > >> gpsd-3.17 > >> > >> I'm a fan of pushing for toolkit migration, so reducing the number of > >> things > >> that pull in GTK2 is a good thing. > >> > >> > >> So if we're expressing hopes that ports might be made GTK2-free (by > >> porting to > >> GTK3 for instance) then I'd hope that fontforge gets that treatment, > >> too. From > >> looking at the source repo, I don't think the GTK2 option actually > >> works (and > >> the comments suggest it's not all that good anyway). In the > >> configure.ac it > >> looks like there are spelling-inconsistencies between > >> fontforge_can_use_gtk=yes > >> and, e.g,, > >> FONTFORGE_ARG_ENABLE_GDK > >> > >> (mtrace depends on fontforge, so fixing fontforge would clean GTK2 off my > >> system) > > > > It is not so simple. What works for you doesn't work for somebody else. > > I am running KDE4 with QT4 but some applications use GTK2 as the only > > option or I set them to use GTK2 because GTK2 has better theme > > integration to KDE4 / QT style than GTK3 (in my personal case). > > And, for example, Total Commander has two choices - QT or GTK2. I tried > > it to build with QT but it failed so I switched to GTK2 and it builds fine. > > So in my current situation I am glad we have GTK2 and GTK3 and all my > > applications are working (better with GTK2 than GTK3). And having both > > GTK versions installed is not a big problem. Their size is relatively > > small compared to apps like browsers, libreoffice etc. > > > > No one is suggesting removing GTK2. However, having most ports, where > there is a choice, defaulting to GTK3 rather than GTK2 might be sensible. > Regards > -- > Niclas Zeising Thank you to everybody who weighed in on this! It sounds like switching the default from GTK2 to GTK3 makes sense, so I will roll that into the Feb 1 update. # Adam -- Adam Weinberger ad...@adamw.org https://www.adamw.org ___ 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 +-+ devel/fb303 | 0.11.0 | 0.12.0 +-+ sysutils/fusefs-libs| 2.9.7 | fuse-2.9.9 +-+ 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
On Fri, 4 Jan 2019 13:31:41 +0100 Kurt Jaeger wrote: > 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 > Thanks, wasn't aware update is already in progress. -- /* * 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"
